Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16)
-Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Aryeh Gregor Sent: 25 September 2009 23:01 To: Wikimedia developers Subject: Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16) On Fri, Sep 25, 2009 at 3:46 PM, Steve Sanbeg ssan...@ask.com wrote: I'm not sure that's entirely accurate. XSLT works on DOM trees, so malformed XML shouldn't really apply. Of course, the standard command line processors create this tree with a standard parser, usually an XML parser. But in PHP, creating the DOM with a parser and transforming it with XSLT are handled separately. Interesting. In that case, theoretically, you could use an HTML5 parser, which is guaranteed to *always* produce a DOM even on random garbage input (much like wikitext!). Now, who's up for writing an HTML5 parser in PHP whose performance is acceptable? I thought not. :P libxml2, and therefore PHP has a tag soup HTML 4 parser. DOMDocument::loadHTML() http://xmlsoft.org/html/libxml-HTMLparser.html Jared ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16)
-Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Aryeh Gregor Sent: 24 September 2009 15:48 To: Wikimedia developers Subject: Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16) On Thu, Sep 24, 2009 at 4:41 AM, Tim Starling tstarl...@wikimedia.org wrote: * Removes a few RTTs for non-pipelining clients Do you mean to imply that there's such a thing as a pipelining client on the real web? (Okay, okay, Opera.) This concern seems like it outweighs all the others put together pretty handily -- especially for script files that aren't at the end, which block page loading. * Automatically create CSS sprites? That would be neat, but perhaps a bit tricky. Just trying to think how it'd work. Given a CSS selector, and an image, should be able to construct a stylesheet which sets the background property of the css rules and an single image. (#toolbar-copy, toolbar-copy.png) (#toolbar-copy:hover, toolbar-copy-hover.png) And the generated stylesheet would get concatenated with other stylesheets. Jared ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16)
On 9/24/09 9:31 AM, Jared Williams wrote: * Automatically create CSS sprites? That would be neat, but perhaps a bit tricky. Just trying to think how it'd work. Given a CSS selector, and an image, should be able to construct a stylesheet which sets the background property of the css rules and an single image. (#toolbar-copy, toolbar-copy.png) (#toolbar-copy:hover, toolbar-copy-hover.png) And the generated stylesheet would get concatenated with other stylesheets. I work with CSS sprites all the time, and have seen some automated methods to go from individual images to sprites, but it's not nearly as good of an idea as it sounds. I will go into depth, but if you don't really care (totally understandable) just understand this. *Automation of sprite creation and implementation is not an efficient use of time in most cases.* First, to use sprites, you have to be in a situation where CSS background-position attributes are not already being used. Take for instance the CSS we use to place little icons next to links that are pointing to external URLs. Essentially we set a background image to be positioned right center and then move the text out of the way with padding-right:18px. If you were to sprite this image, you could perhaps use a vertical sprite (images tiled vertically only) but then when the user adjusts the size of the text in their browser they start seeing multiple images on the right. You could add more space between the images so that the text could be pretty big before you start seeing the other icons, but how much space is enough? What limit on text-size adjustment should we declare? Does the extra space between the icons introduce a significant amount of additional data? (maybe not much with PNG compression techniques, but it does add something) In many other cases the background position in both X and Y are being used already so sprites are not a possibility at all. To use sprites like Google does, you would need to change the HTML output to accommodate the technique. For instance you could insert a fixed sized float:right div as an icon at the end of the link, but then the elegant way that we apply styles to such links (rules like a[href^=http://];) are useless... We would have to make changes to the output of the parser for purely aesthetic reasons (evil), or perform client-side DOM manipulations (requiring JavaScript to to be enabled just to see the external link icon - also evil) --- this is getting messy. My point is not that sprites are bad, it's that they aren't always an option, and take allot of careful design of CSS, HTML and image resources to get working properly. Automating them as is starting to be proposed here includes inventing some sort of instruction set that a computer can read and assemble sprites from, but the problem is usually so complex that such a language would take much more time to invent, create parsers for, test and maintain than to just do the sprites by hand. Automating sprite creation is still a great idea, but it needs to be done in more isolated and predictable cases like generating toolbar icons. This case is more firendly to automation because it's dealing with fixed height and width images that are always displayed in the browser at the same size no matter what. Thes files are currently stored in separate files, so merging them into a single file and generating CSS code that defines the offsets for them to be put to use using automation would be great!. However even this case has it's issues. It makes the toolbar code more complex because we have to support sprite-based images as well as non-sprite-based images (so that users can still customize the toolbar) and we have to handle the naming of the selectors of the generated CSS in some way that won't cause confusion or namespace collision. Finally, the png or gif files that are created by things like ImageMagick are larger (in bytes) than images compressed by hand (using image manipulation software). Even pngcrush or similar utilities fail to outperform manual image compression. The reason is that images can be reduced in size, but when you do this it reduces the quality (fewer colors in the pallete make the image look more grainy, aggressive jpeg compression makes the image look more blocky). When performing image compression manually, you use your eyes and image processing in your brain to decide where the line should be drawn between quality and optimization - automated solutions I've used seem to either draw this line arbitrarily or error on the side of quality at the cost of optimal compression. So - not only does the CSS and HTML need close attention when working with sprites, but the image optimization process does as well. Again, I like sprites allot! But in reality, they are an optimization technique that needs careful attention and can cause problems if done improperly. - Trevor
Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16)
-Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Trevor Parscal Sent: 24 September 2009 19:38 To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16) On 9/24/09 9:31 AM, Jared Williams wrote: * Automatically create CSS sprites? That would be neat, but perhaps a bit tricky. Just trying to think how it'd work. Given a CSS selector, and an image, should be able to construct a stylesheet which sets the background property of the css rules and an single image. (#toolbar-copy, toolbar-copy.png) (#toolbar-copy:hover, toolbar-copy-hover.png) And the generated stylesheet would get concatenated with other stylesheets. Again, I like sprites allot! But in reality, they are an optimization technique that needs careful attention and can cause problems if done improperly. Providing CSS sprite support would be (I guess) just a service for modules/extensions to use, just as a part of the proposed client resource manager(?). So the mediawiki or an extension can put in a request for a some stylesheet or javascript be linked to, it could also request for images possibly via CSS sprites. So don't see how it should cause a problem. Jared ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16)
On 9/24/09 1:40 PM, Jared Williams wrote: -Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Trevor Parscal Sent: 24 September 2009 19:38 To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16) On 9/24/09 9:31 AM, Jared Williams wrote: * Automatically create CSS sprites? That would be neat, but perhaps a bit tricky. Just trying to think how it'd work. Given a CSS selector, and an image, should be able to construct a stylesheet which sets the background property of the css rules and an single image. (#toolbar-copy, toolbar-copy.png) (#toolbar-copy:hover, toolbar-copy-hover.png) And the generated stylesheet would get concatenated with other stylesheets. Again, I like sprites allot! But in reality, they are an optimization technique that needs careful attention and can cause problems if done improperly. Providing CSS sprite support would be (I guess) just a service for modules/extensions to use, just as a part of the proposed client resource manager(?). So the mediawiki or an extension can put in a request for a some stylesheet or javascript be linked to, it could also request for images possibly via CSS sprites. So don't see how it should cause a problem. Jared ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l So you are saying that you believe a generic set of sprite-generation utilities are going to be able to completely overcome the issues I identified and be a better use of time (to design, develop and use) than just creating and using sprites manually? - Trevor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16)
-Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Trevor Parscal Sent: 24 September 2009 21:49 To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16) On 9/24/09 1:40 PM, Jared Williams wrote: -Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Trevor Parscal Sent: 24 September 2009 19:38 To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16) On 9/24/09 9:31 AM, Jared Williams wrote: * Automatically create CSS sprites? That would be neat, but perhaps a bit tricky. Just trying to think how it'd work. Given a CSS selector, and an image, should be able to construct a stylesheet which sets the background property of the css rules and an single image. (#toolbar-copy, toolbar-copy.png) (#toolbar-copy:hover, toolbar-copy-hover.png) And the generated stylesheet would get concatenated with other stylesheets. Again, I like sprites allot! But in reality, they are an optimization technique that needs careful attention and can cause problems if done improperly. Providing CSS sprite support would be (I guess) just a service for modules/extensions to use, just as a part of the proposed client resource manager(?). So the mediawiki or an extension can put in a request for a some stylesheet or javascript be linked to, it could also request for images possibly via CSS sprites. So don't see how it should cause a problem. Jared ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l So you are saying that you believe a generic set of sprite-generation utilities are going to be able to completely overcome the issues I identified and be a better use of time (to design, develop and use) than just creating and using sprites manually? - Trevor I wouldn't say there a issues with CSS sprites, but there are limitations which you have to be aware of before deciding on using them, and therefore do not need overcoming. In the context of providing toolbar imagery for UIs like a WYSIWYG editor, or for playing video, audio, or for simple image editing, they can remove a lot of round triping. Jared ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16)
On 9/24/09 2:34 PM, Jared Williams wrote: -Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Trevor Parscal Sent: 24 September 2009 21:49 To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16) On 9/24/09 1:40 PM, Jared Williams wrote: -Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Trevor Parscal Sent: 24 September 2009 19:38 To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16) On 9/24/09 9:31 AM, Jared Williams wrote: * Automatically create CSS sprites? That would be neat, but perhaps a bit tricky. Just trying to think how it'd work. Given a CSS selector, and an image, should be able to construct a stylesheet which sets the background property of the css rules and an single image. (#toolbar-copy, toolbar-copy.png) (#toolbar-copy:hover, toolbar-copy-hover.png) And the generated stylesheet would get concatenated with other stylesheets. Again, I like sprites allot! But in reality, they are an optimization technique that needs careful attention and can cause problems if done improperly. Providing CSS sprite support would be (I guess) just a service for modules/extensions to use, just as a part of the proposed client resource manager(?). So the mediawiki or an extension can put in a request for a some stylesheet or javascript be linked to, it could also request for images possibly via CSS sprites. So don't see how it should cause a problem. Jared ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l So you are saying that you believe a generic set of sprite-generation utilities are going to be able to completely overcome the issues I identified and be a better use of time (to design, develop and use) than just creating and using sprites manually? - Trevor I wouldn't say there a issues with CSS sprites, but there are limitations which you have to be aware of before deciding on using them, and therefore do not need overcoming. In the context of providing toolbar imagery for UIs like a WYSIWYG editor, or for playing video, audio, or for simple image editing, they can remove a lot of round triping. Jared ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Sounds like we agree. The issues weren't issues with sprites, they were issues with automating them. - Trevor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
