Re: [whatwg] [html5] Semantic elements and spec complexity
On Thu, 11 Nov 2004, Matthew Thomas wrote:
>
> I believe the past 15 years of semantic markup have shown these three
> things to be true:
>
> 1. Most authors Just Don't Care about semantic markup. They'll only use
> it if it's the easiest way of getting the visual effect or behavior
> they want in their own favorite browser, or if they can use it to
> game search engines. (That's why authors use and , for
> example, but not .)
I don't know if the thrust of this argument is true, but I am pretty sure
the parenthetical isn't. If authors don't use I think it's
because of a variety of reasons including its poor name, and its lack of
particularly useful purpose.
I think there is a wide range of authoring styles, ranging from the author
who really hasn't any idea that there is such a thing as semantics, and
just thinks visually, to the author who just wants to get stuff done but
understands that there are elements for specific purposes like lists, to
the author who has bought the semantics religion but doesn't really
understand it, leading to all kinds of "innovative" (and wrong) uses of
HTML's less well known elements.
> 2. Those authors who do care about semantic markup often do so
> overzealously, using it even when it's not appropriate. For example,
> they use whenever they want italics or whenever they
> want bold.
There are certainly authors who misuse semantic markup for reasons other
than desiring presentational effects, yes.
> 3. The more complex a markup language, the fewer people understand it,
> the less conformant the average article will be, so the less useful
> the Web's semantics will be. Current HTML authors may clamour for
> new features, but they have forgotten what it was like to be a new
> HTML author; and new authors are neither subscribed to this list nor
> employed by browser vendors, so it is easy to forget about them.
Agreed.
> So if , , , , , and
> are introduced, with the default presentation currently suggested {display:
> block; margin: 0;}, I predict the following:
>
> * The A-list of Web developers will begin using all the elements
> correctly on their Weblogs, and they will feel good about it.
>
> * A greater number of Web developers will never use most of these
> elements, but they will replace all occurrences of on their
> pages with because it's more "semantic" (just like they
> did with for and for ), and they will feel good
> about it.
>
> * The vast majority of article producers (Weblogs and online
> newspapers) will never use , because there's no visual or
> behavioral benefit from doing so. So will never become a
> reliable way of dissecting or aggregating pages.
>
> * The number of knowledgable HTML authors, the proportion of HTML
> pages that are valid, and therefore the overall usefulness of the
> Web, will be less than it otherwise would have been because of
> HTML's increased complexity.
I don't really think that such a dire consequence is likely.
> One way of improving this situation would be to reduce the number of new
> elements -- forget about and , for example.
These elements map pretty closely to common class values (in particular
footer is the most common class name), so I don't think this is
necessarily a good way to go.
> Another way would be to recommend more distinct default presentation for each
> of the elements -- for example, default to having a drop cap,
> default to floating right, default , , and
> to having a slightly darker background than their parent element,
> and default ... and ... to inline presentation. This
> would make authors more likely to choose the appropriate element.
I agree that this would be interesting. However, I'm at a loss as to what
styles to use. Doing things like drop caps sounds cool, but in practice I
fear it would actually discourage use due to weirdness and people not
knowing how to override it (you'd have to do "article > p:first-line {
font-variant: normal; }", which is pretty esoteric for the authors you
mentioned just a little earlier).
Similarly, floating sounds like a good idea until you start considering
how to make it interact with other text -- you'd need margins, and
probably a top and bottom border, and padding, and a min-width, and a
max-width... and soon you're at a level so complex that new authors are
never going to be able figure it out, which defeats the whole point.
> A complementary long-term approach would be to deprecate the most
> redundant and/or least effectual elements and attributes from HTML 4.01
> -- for example, , , , , , accesskey=,
> cite=, longdesc=, and name= -- in preparation for removing them. This
> would eventually help reduce the complexity of the spec.
Many of these, and many others, are indeed obsoleted in HTML5.
On Wed, 10 Nov 2004, James Graham wrote:
>
> This isn't really true, in general. For example, many
Re: [whatwg] Video playback quality metric
On Mon, 09 Feb 2009 22:13:09 +0100, Jeremy Doig wrote: Measuring the rate at which the playback buffer is filling/emptying gives a fair indication of network goodput, but there does not appear to be a way to measure just how well the client is playing the video itself. If I have a wimpy machine behind a fat network connection, you may flood me with HD that I just can't play very well. The cpu or video card may just not be able to render the video well.Exposing a metric (eg: Dropped Frame count, rendered frame rate) would allow sites to dynamically adjust the video which is being sent to a client [eg: switch the url to a differently encoded file] and thereby optimize the playback experience. Anyone else think this would be good to have ? While I think this kind of thing might be useful, I would be careful about requiring any kind of detailed metrics like dropped frames or effective frame rate to be exposed via DOM, as getting this information reliably over different devices, platforms and media frameworks would be quite difficult. How about an event which the user agent can optionally fire to indicate that it cannot play at the requested rate due to processing/memory constraints (rather than network)? This would (I think) provide the same functionality but put less burden on implementors. There is already a placeholder for non-fatal errors in the spec, perhaps this could be included with that in some fashion? -- Philip Jägenstedt Opera Software
Re: [whatwg] [web-apps] Ability to treat transparent part of element transparent to events
On Tue, 11 Jan 2005, martijnw wrote: > > See: > https://bugzilla.mozilla.org/show_bug.cgi?id=102695 - Treat some transparent > elements as "transparent to events" > I think that explains basically what I would like to have. > Afaik, that's something that IE is already doing (at least I heard). > Basically, I was thinking about some sort of attribute that would enable this > behavior. > Is this something worth considering for the Web Applications spec? Apparently the CSS group is considering applying the 'pointer-events' property to HTML content as well as SVG, so this is an issue for the www-style mailing list now. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] Semantic elements and spec complexity
On Tue, 10 Feb 2009 10:02:36 +0100, Ian Hickson wrote: > , default , , and to having a slightly > darker background than their parent element It seems like there should be something more obvious that could be done for these elements. For and a border below and above, respectivly, would seem obvious. That would be simple enough, I guess; what do other people think? I think many authors hate default styles so much that they either prefer to just use or they start their style sheet with resetting the defaults. Since is intended to be useful to make subheaders not appear in the ToC, the move from Foo Bar to Foo Bar shouldn't, IMHO, result in ugly borders that everyone has to nuke (compare with ). -- Simon Pieters Opera Software
Re: [whatwg] [html5] Semantic elements and spec complexity
On Tue, 10 Feb 2009, Simon Pieters wrote: > On Tue, 10 Feb 2009 10:02:36 +0100, Ian Hickson wrote: > > > > , default , , and to having a > > > > slightly darker background than their parent element > > > > > > It seems like there should be something more obvious that could be > > > done for these elements. For and a border below > > > and above, respectivly, would seem obvious. > > > > That would be simple enough, I guess; what do other people think? > > I think many authors hate default styles so much that they either prefer > to just use or they start their style sheet with resetting the > defaults. > > Since is intended to be useful to make subheaders not appear in > the ToC, the move from > > Foo > Bar > > to > > >Foo >Bar > > > shouldn't, IMHO, result in ugly borders that everyone has to nuke > (compare with ). Yeah, that's a good point. I've left it at just display:block. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Video playback quality metric
Jeremy Doig wrote: Measuring the rate at which the playback buffer is filling/emptying gives a fair indication of network goodput, but there does not appear to be a way to measure just how well the client is playing the video itself. If I have a wimpy machine behind a fat network connection, you may flood me with HD that I just can't play very well. The cpu or video card may just not be able to render the video well.Exposing a metric (eg: Dropped Frame count, rendered frame rate) would allow sites to dynamically adjust the video which is being sent to a client [eg: switch the url to a differently encoded file] and thereby optimize the playback experience. Anyone else think this would be good to have ? It seems like, in the short term at least, the "worse is better" solution to this problem is for content providers to provide links to resources at different quality levels, and allow users to choose the most appropriate resource based on their internet connection and their computer rather than having the computer try to work it out for them. Assuming that the majority of users use a relatively small number of sites with the resources to provide multiple-quality versions of their videos and use a small number of computing devices with roughly unchanging network conditions (I imagine this scenario applies to the majority of non-technical), they will quickly learn which versions of the media works best for them on each site. Therefore the burden of this simple approach on end users does not seem to be very high. Given this, I would prefer automatic quality negotiation be deferred to HTML6.
Re: [whatwg] [html5] Semantic elements and spec complexity
Since is intended to be useful to make subheaders not appear in the ToC, the move from Foo Bar to Foo Bar shouldn't, IMHO, result in ugly borders that everyone has to nuke (compare with ). Yeah, that's a good point. I've left it at just display:block. Four-and-a-bit years on I tend to agree :)
Re: [whatwg] MediaModeAbstractView and changing of media dynamically
On Wed, 20 Sep 2006, Anne van Kesteren wrote: > On Tue, 19 Sep 2006 23:27:12 -, Joao Eiras wrote: > > > > So, I suggest the creation of the 'media-change' event, which will > > fire when the UA changes media, having the document as target. The > > event object could be an instance of a UIEvent, and have 2 extra > > properties: newMediaMode, and oldMediaMode. > > This has already been suggested multiple times on this list. Personally, > I think a better place is probably the new CSSOM (whenever I get around > to it...). I agree that this would be better in CSSOM. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Video playback quality metric
On Tue, 10 Feb 2009 04:38:01 -0500, James Graham wrote:
Jeremy Doig wrote:
Measuring the rate at which the playback buffer is filling/emptying
gives a
fair indication of network goodput, but there does not appear to be a
way to
measure just how well the client is playing the video itself. If I have
a
wimpy machine behind a fat network connection, you may flood me with HD
that
I just can't play very well. The cpu or video card may just not be able
to
render the video well.Exposing a metric (eg: Dropped Frame count,
rendered
frame rate) would allow sites to dynamically adjust the video which is
being
sent to a client [eg: switch the url to a differently encoded file] and
thereby optimize the playback experience.
Anyone else think this would be good to have ?
It seems like, in the short term at least, the "worse is better"
solution to this problem is for content providers to provide links to
resources at different quality levels, and allow users to choose the
most appropriate resource based on their internet connection and their
computer rather than having the computer try to work it out for them.
Assuming that the majority of users use a relatively small number of
sites with the resources to provide multiple-quality versions of their
videos and use a small number of computing devices with roughly
unchanging network conditions (I imagine this scenario applies to the
majority of non-technical), they will quickly learn which versions of
the media works best for them on each site. Therefore the burden of this
simple approach on end users does not seem to be very high.
Given this, I would prefer automatic quality negotiation be deferred to
HTML6.
Flash has low, medium and high quality that the user can change (although a lot of
sites/players seem to rudely disable that option in the menu for some reason). This helps
out a lot and can allow a video to play better. I could imagine an "Auto"
option too that automatically switched quality as necessary to get decent playback.
As an event, a site could use it like:
video.onplaybacktooslow = function() {
this.quality = "low";
this.setToNativeSize(); // stretched videos use more cpu
};
Or, something like that.
--
Michael
Re: [whatwg] Hyphenation
On Tue, 9 Jan 2007, �istein E. Andersen wrote: > > Hyphenation does not seem to have been discussed on this list so far, > and I think it should be. > > Old proposal: > [2] http://www.nada.kth.se/i18n/html/hyph.html While I appreciate the problems faced by Swedish, German, and othes, I don't think this is a big enough problem to deserve solutions more complicated than the soft hyphen at this time. Given that Unicode provides soft hyphen semantics and CSS provides the rendering rules, I don't think there is anything much for HTML5 to say on the matter at this time. This thread included many further e-mails discussing the subject. I agree with most of the points made. There did not seem to be a consensus that this is something that HTML5 should do anything about. If hyphenation dictionaries are to be used, it seems CSS would be the best place for them. I haven't done anything in HTML5 to handle them. As usual, please let me know if there is something I missed. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Ideas regarding Web Applications 1.0
On Mon, 12 Mar 2007, Nicholas Shanks wrote: > On 28 Feb 2007, at 05:38, Ian Hickson wrote: > > > For example, your page-wide header might need shortening on handheld > > media. I don't have a good proposal for this. Maybe we need the > > opposite of ? > > We already have the opposite of the abbr element. It's called� the abbr > attribute (for th elements). And yes, it would be nice, though not > really essential, if there were a blessed mechanism for specifying > different titles for different display media. This can be achieved > through CSS media queries & CSS3's "content" property at present, and I > don't think the usage case is sufficient to warrant an extension of > HTML. Agreed. I haven't added anything for this case. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] How to improve the appearance of web pages
On Tue, 13 Mar 2007, Behnam ZWNJ Esfahbod wrote: > > Implementing a new web application from scratch, I found out some new > ideas to make the appearance of site better. I'm not sure here are the > best place for this discussion, but at least it's not out of interest. > > First one is how Mozilla/Firefox do the zooming thing, "Text Size". On > web sites with images, changing the text size just works for +/- 2 > levels. More than that the whole page gets out of shape. Seems Gecko > 1.9/Firefox 3 is going to resize images, but I'm not sure. > > BTW the first trick is how to make images "zoomable", by the ratio of > "Text Size". I set an style attribute for each image (which are not a > lot, limited to the logos) which sets "font-size" to image's width (in > pixel) and set the image's "width" to "1em". It works well on Fx2.0 and > IE6. > > The problem is there's no way to do it globaly, and I should add a > "style" attribute to each "img" tag. > > Something I found weird is the default unit of images without width and > height attributes. If there was a way to just set the default unit of > images to "em", the problem could be solved. The problem is better solved using actual pixel zoom, rather than text zoom. Most browsers do this now. > The second one is to get the web server decide which image file is > better. An Apache httpd module can select the best response for a > request for image "the-company-logo" if it knows which size is needed, > and what mime-types are acceptable. > > My idea is to add a field to the http request header for image files, to > let the server know which size the image is going to be shown, and then > it decides to send the best answer. [...] > > Another usage is when the browser does the zooming. When I zoom in the > page 200%, that's good if browser can get the company logo with better > quality. It would be just another request for "the-company-logo" with > the 384 pixels width, and it may be a bitmap or vector file again. [...] I recommend bringing this up with the HTTP working group, as it seems out of scope for HTML5. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Default (informal) Style Sheet
On Sun, 1 Apr 2007, Kempen, E.J.F. van wrote:
> >
> > [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Asbj�rn Ulsberg
> >
> > While HTML is a semantic markup language, it's not something to ignore
> > that it's mostly used for visual rendering of content, often
> > accompanied by a CSS document. While I'm a strong believer of
> > separation between structure (HTML), presentation (CSS) and
> > functionality (JavaScript), I think it could be useful for the HTML
> > specification to -- within limits -- define how each and every
> > element's default CSS properties and values should be like.
>
> I totally agree with you at the point of the importance of layer
> separation, but I'm not sure about specifying the default CSS values.
> There are a few options:
>
> * let the CSS be built from scratch *
> No styles are defined, so by default the CSS values are empty. I don't
> think this a good option, because people won't define their styles from
> scratch, resulting in vendors still needing to define default styles. So
> that's no solution.
>
> * Vendors keep defining the default values for every element *
> If a web developer disagrees with the vendors, he will just define it in
> his CSS.
>
> * the HTML WG defines default values for every element *
> This can be a solution for HTML as web representation. Defining defaults
> can result in vendors implementing the same defaults, so it looks the
> same in every browser by default. I think it's good to think about these
> things, but I wonder if it would change anything.
>
> What exactly are you looking for? Defining that 'normal' text is black
> by default and links are blue-ish? Because that's done already, most
> default styles are uniformly, but maybe informally, defined. As the new
> HTML spec is gradually being developed, a new document could be written
> about default styles, but I don't think this should be in the new HTML
> spec. I personally think such a complementary document, about the
> default styles, is a good idea. These issues should certainly be
> addressed in cooperation with the CSS WG.
The rendering section now does a mixture of the above.
On Sun, 1 Apr 2007, Martin Atkins wrote:
>
> One example that springs to mind is that the default CSS rules for
> unordered and ordered lists differ between browsers. Some implement the
> bullets with padding and list-style, while others use margins and
> god-knows-what. I can't really remember anymore. I've just learned that
> the way to get rid of the bullets across all popular browsers is:
>
> ul, ul li {
> margin: 0;
> padding: 0;
> list-style: none;
> }
>
> If you don't set both margin and padding, you'll see inconsistent
> results.
The spec now picks one.
On Mon, 2 Apr 2007, Asbj�rn Ulsberg wrote:
>
> With CSS2.1, how would you style the button you get from an type="file"> for instance?
is a special case, due to the security aspects.
In general, though, XBL is the only way to get to the bits of a widget,
and that isn't implemented yet.
> > I personally think such a complementary document, about the default
> > styles, is a good idea. These issues should certainly be addressed in
> > cooperation with the CSS WG.
> >
> > Any other thoughts?
>
> If the HTML spec is going to contain informal fragments of Relax-NG, I
> believe there's a place for informal fragments of CSS as well.
It isn't going to have the former. :-) The latter aren't really informal,
they're a kind of half-way-required level.
On Sun, 1 Apr 2007, Sander Tekelenburg wrote:
> >
> > http://www.whatwg.org/specs/web-apps/current-work/#rendering
>
> That saying "when scrolling a page to a fragment identifier, align the
> top of the viewport with the target element's top border edge", seems to
> emphasize my argument. This is a silly requirement.
This is now gone.
On Mon, 2 Apr 2007, Asbj�rn Ulsberg wrote:
>
> Speaking of , having a default style for it would increase
> interoperability (if only in the presentation layer) a great deal.
Done.
This thread discussed a number of philosophical topics and it wasn't clear
what a lot of it translated to, in terms of practical changes to the spec.
I didn't reply to those bits. Please let me know if I missed some
important feedback that should affect the spec.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hyphenation
Ian Hickson schrieb: On Tue, 9 Jan 2007, �istein E. Andersen wrote: Hyphenation does not seem to have been discussed on this list so far, and I think it should be. Old proposal: [2] http://www.nada.kth.se/i18n/html/hyph.html While I appreciate the problems faced by Swedish, German, and othes, I don't think this is a big enough problem to deserve solutions more complicated than the soft hyphen at this time. Jukka Korpela stated that the intention of the soft hyphen is not actually a hyphenation hint: http://www.cs.tut.fi/~jkorpela/shy.html (Anyway I don't really understand the difference between a normal hyphen and a soft hyphen then...) Given that Unicode provides soft hyphen semantics and CSS provides the rendering rules, I don't think there is anything much for HTML5 to say on the matter at this time. This thread included many further e-mails discussing the subject. I agree with most of the points made. There did not seem to be a consensus that this is something that HTML5 should do anything about. If hyphenation dictionaries are to be used, it seems CSS would be the best place for them. I haven't done anything in HTML5 to handle them. The wish for an in-text hyphenation mechanism is of course motivated by the habit of how we do it in office and layout softwares, where text and presentation are not separated. I totally agree that the appropriate place for it is presentation, thus CSS, and the CSS3 draft looks quite reasonable: http://www.w3.org/TR/2007/WD-css3-gcpm-20070205/#hyphenation Anyway I don't find anything about the format of the hyphenation dictionary. To replace in-text hyphenation hints it is necessary to have several levels of hyphenation quality - the german word for "hyphenation mechanism" for example, "Trennungsmechanismus", you might want to have hyphentated at any possible place inside body text, but only at "Trennungs-mechanismus" in a headline. I see that this list is not the appropriate place for suggestions about CSS3 properties - maybe someone can point me to the appropriate place?
Re: [whatwg] Hyphenation
On Tue, 10 Feb 2009, Markus Ernst wrote: > > > > While I appreciate the problems faced by Swedish, German, and othes, I > > don't think this is a big enough problem to deserve solutions more > > complicated than the soft hyphen at this time. > > Jukka Korpela stated that the intention of the soft hyphen is not > actually a hyphenation hint: http://www.cs.tut.fi/~jkorpela/shy.html As far as I can tell this is a non-issue; HTML5 defers to Unicode for the semantics of its characters, and Unicode is clear here. HTML5 doesn't support ISO 8859-1 (it always treats content labeled as such as a Win1252 mapping to Unicode). > The wish for an in-text hyphenation mechanism is of course motivated by > the habit of how we do it in office and layout softwares, where text and > presentation are not separated. I totally agree that the appropriate > place for it is presentation, thus CSS, and the CSS3 draft looks quite > reasonable: http://www.w3.org/TR/2007/WD-css3-gcpm-20070205/#hyphenation > > Anyway I don't find anything about the format of the hyphenation > dictionary. To replace in-text hyphenation hints it is necessary to have > several levels of hyphenation quality - the german word for "hyphenation > mechanism" for example, "Trennungsmechanismus", you might want to have > hyphentated at any possible place inside body text, but only at > "Trennungs-mechanismus" in a headline. I see that this list is not the > appropriate place for suggestions about CSS3 properties - maybe someone > can point me to the appropriate place? www-st...@w3.org is the appropriate place. See the "Status of this document" section of the draft you cite above. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hyphenation
Markus Ernst writes: > Ian Hickson schrieb: > > > I don't think this is a big enough problem to deserve solutions more > > complicated than the soft hyphen at this time. > > Jukka Korpela stated that the intention of the soft hyphen is not > actually a hyphenation hint: > http://www.cs.tut.fi/~jkorpela/shy.html He claims that there are multiple standards that contradict each other. So whatever is implemented is bound to contravene at least one of them. However he mentions that: * HTML 4 defines it as a hyphenation hint. * Unicode defines it as a hyphenation hint. * Recent browsers are now treating it as a hyphenation hint. * The contradictory standard (ISO-8859) only defines a soft hyphen when used at the end of a line, namely that it should be rendered like a hyphen. Since that standard doesn't envisage the character being used elsewhere, it is silent on how it should be rendered. It seems to me that choosing to render invisibly a soft hyphen which isn't at the end of a line doesn't contradict the text of ISO-8859 (though it could be argued to contradict its spirit). > (Anyway I don't really understand the difference between a normal > hyphen and a soft hyphen then...) Suppose you are reflowing some text (perhaps because you are quoting it); words which were broken over lines in the original may want rejoining into a single word in your version (that is, the soft hyphen disappears); but hyphens (non-soft) between two words need to remain. Smylers
Re: [whatwg] Default (informal) Style Sheet
On Tue, 10 Feb 2009 11:52:32 +0100, Ian Hickson wrote: Speaking of , having a default style for it would increase interoperability (if only in the presentation layer) a great deal. Done. Excellent! -- Asbjørn Ulsberg -=|=- asbj...@ulsberg.no «He's a loathsome offensive brute, yet I can't look away»
Re: [whatwg] Video playback quality metric
On Tue, Feb 10, 2009 at 1:54 AM, Michael A. Puls II wrote: > Flash has low, medium and high quality that the user can change (although a > lot of sites/players seem to rudely disable that option in the menu for some > reason). This helps out a lot and can allow a video to play better. I could > imagine an "Auto" option too that automatically switched quality as > necessary to get decent playback. Isn't that rendering quality? That can of course be adjusted by the browser, dynamically and/or according to a user setting, with or without a javascript interface. -r
Re: [whatwg] Color attributes
On Thu, 16 Oct 2008, Simon Pieters wrote: > > Color attributes in HTML have special processing. [...] > > It seems that some pages use three-digit notation and expect it to work > as in CSS. I've made the algorithm do that and I've drafted up a spec > for this: > >http://simon.html5.org/specs/html-color-attributes The spec now defines this. Thanks for your work on this. It was hugely helpful. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Load SVG via IMG element
On Thu, 4 Oct 2007, Vlad Alexander (xhtml.com) wrote: > > I noticed that Opera 9.5 can load an SVG image via the IMG element. I > think this is a wonderful thing. Is there any specification on how this > should work? For example, I noticed that Opera, for some reason, does > not scale SVG images to fit the box created by the IMG element's width > and height attributes. Here is a test page: > > http://xhtml.com/misc/svg-img.htm > > Can someone please point me to any specs on loading SVG via IMG element? On Fri, 5 Oct 2007, Devi Web Development wrote: > > My understanding is that SVG should not be scaled to fit given > dimensions because scaling information is provided in the SVG itself. I > don't know about the full status of SVG in browsers, but I know that > Firefox supports some, and the Adobe plug-in is common. A full test > suite is available at http://www.w3.org/Graphics/SVG/Test/ A > specification for embedding SVG in XHTML can be found at > http://www.w3.org/TR/XHTMLplusMathMLplusSVG/ and Mozilla provides some > documentation at > http://developer.mozilla.org/en/docs/SVG_In_HTML_Introduction It's not clear to me what I should say in HTML5 about this. should just do whatever the image format says it should do, right? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [HTML5] Accessibility question
On Sat, 22 Mar 2008, Nicholas C. Zakas wrote: > > Apologies for not replying sooner, I've been struck with a bit of the > flu. > > The problem I'm trying to solve is the case where you need descriptive > text for screen readers but that text is not necessary for sighted > users. For example, our accessibility guidelines at Yahoo! say that > every unordered list () should be preceeded by a header that > describes its use. The header may say something like "Page options" or > "Available styles" and we use CSS tricks (text-indent: -1px;) to > hide these headings from display while allowing screen readers to read > them. To sighted users, the meaning of the list is apparent because they > can see the visual treatments we've applied whereas blind users would > just hear a list read out of context. > > Another example is for buttons that make use of sprites. Something is > implemented as a link but with a background image that's part of a > sprite. The link needs to have descriptive text for screen readers but > the text is unnecessary for sighted users as they can see the image. For > example: > > Close > > For things like this, I usually end up using the same CSS trick > mentioned above to move the "Close" text out of the way. Just looking at > the HTML, it's not apparent that "Close" is not intended to seen. > Whereas the following clears it up: > > Close > > Now I know from looking at the source code that "Close" is clearly not > intended to be seen. This seems like a CSS problem. The text is only inapplicable because of the CSS, right? If the CSS wasn't applied, then even on a screen, the user would need the titles or button text you've described. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Warnings for non-applicable properties
On Mon, 10 Nov 2008, Paul Arzul wrote: > > is it unfortunate that the html4 stylesheet is only informative? perhaps > html5 could then consider giving us a normative default user agent > stylesheet - or at least a normative version with only display > properties. The spec has a semi-normative one now. User agents aren't required to follow it, because we never know when they might apply styles for particular users with special needs. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=image width/height attributes
On Tue, 23 Dec 2008, Kartikaya Gupta wrote: > > Are there any plans to add the width/height attributes for the input > element to the HTML5 spec? It seems that all browsers (Opera, FF, > Safari, IE) support width/height on and standards mode. There are websites that depend on this behavior (the > select-your-postal-code landing page at canadiantire.ca is one example) > and it doesn't seem to be specced anywhere that I could find. They're specified now. Thanks, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Warnings for non-applicable properties
Ian Hickson wrote: On Mon, 10 Nov 2008, Paul Arzul wrote: is it unfortunate that the html4 stylesheet is only informative? perhaps html5 could then consider giving us a normative default user agent stylesheet - or at least a normative version with only display properties. The spec has a semi-normative one now. User agents aren't required to follow it, because we never know when they might apply styles for particular users with special needs. Could that arguably be considered to be a machine-generated user stylesheet? I tend to think of the settings my browser has for choosing default fonts and so forth to be functionally equivalent to me writing a user stylesheet that contains the same settings. This would allow the HTML spec to normatively require browsers to use a particular default stylesheet (or, indeed, act as if they've done so) while still allowing for user-specific alterations of various kinds. (I believe that Mozilla is already implemented as above, more or less.)
Re: [whatwg] Load SVG via IMG element
In the message below, Ian Hickson wrote: It's not clear to me what I should say in HTML5 about this. should just do whatever the image format says it should do, right? I would think so, but I cc-ed Doug Schepers on this who might know of a reason not to. I seem to recall some discussion of this somewhere, but if you didn't find it, Ian, then I doubt that I could. David btw, though off-topic here, the question from Vlad about browser support can be answered from Jeff Schiller's up-to-date info on implementations of the SVG spec at http://www.codedread.com/svg-support.php . In brief, all major browsers are implementing quite a bit of SVG natively now except for IE which still relies on a third party plugin. Opera does almost all of SVG1.1 and WebKit is quite far along with SMIL (SVG animation). - Original Message - From: "Ian Hickson" To: "Vlad Alexander (xhtml.com)" ; "Devi Web Development" Cc: Sent: Tuesday, February 10, 2009 8:15 PM Subject: Re: [whatwg] Load SVG via IMG element On Thu, 4 Oct 2007, Vlad Alexander (xhtml.com) wrote: I noticed that Opera 9.5 can load an SVG image via the IMG element. I think this is a wonderful thing. Is there any specification on how this should work? For example, I noticed that Opera, for some reason, does not scale SVG images to fit the box created by the IMG element's width and height attributes. Here is a test page: http://xhtml.com/misc/svg-img.htm Can someone please point me to any specs on loading SVG via IMG element? On Fri, 5 Oct 2007, Devi Web Development wrote: My understanding is that SVG should not be scaled to fit given dimensions because scaling information is provided in the SVG itself. I don't know about the full status of SVG in browsers, but I know that Firefox supports some, and the Adobe plug-in is common. A full test suite is available at http://www.w3.org/Graphics/SVG/Test/ A specification for embedding SVG in XHTML can be found at http://www.w3.org/TR/XHTMLplusMathMLplusSVG/ and Mozilla provides some documentation at http://developer.mozilla.org/en/docs/SVG_In_HTML_Introduction It's not clear to me what I should say in HTML5 about this. should just do whatever the image format says it should do, right? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Warnings for non-applicable properties
On Tue, 10 Feb 2009, Martin Atkins wrote: > Ian Hickson wrote: > > On Mon, 10 Nov 2008, Paul Arzul wrote: > > > is it unfortunate that the html4 stylesheet is only informative? perhaps > > > html5 could then consider giving us a normative default user agent > > > stylesheet - or at least a normative version with only display properties. > > > > The spec has a semi-normative one now. User agents aren't required to follow > > it, because we never know when they might apply styles for particular users > > with special needs. > > Could that arguably be considered to be a machine-generated user > stylesheet? Does it make any difference? The net result is that the user and the author can't rely on a single style sheet. What benefit would a definite UA style sheet be, if not that? > This would allow the HTML spec to normatively require browsers to use a > particular default stylesheet (or, indeed, act as if they've done so) > while still allowing for user-specific alterations of various kinds. There wouldn't be much point to that requirement, since it couldn't be usefully tested. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOM Storage feedback
On Tue, Jan 13, 2009 at 4:53 PM, Cameron McCormack wrote: > Jonas Sicking: >> So it behaves different from passing in an empty string? For some >> functions this surprises me, such as for the namespace parameter for >> getAttributeNS, I would think that we there treat "" the same as null. > > Not necessarily, but I agree that would be a better thing to report. > I'll rejig the tests to get that information. > > Cameron McCormack: >> > OK. So what is more important for choosing the default: fewer >> > exceptions (and thus fewer [Null=…] things polluting the IDL), >> > consistency with the default stringification behaviour of ECMAScript, >> > or avoiding the somewhat counterintuitive default behaviour of >> > converting a valid value of the type to a different value of that type? > >> "converting a valid value of the type to a different value of that >> type", which values exactly? > > null. It feels slightly strange to me to treat null as a "second class > value" by default. But I'll get over it. :-) The point would be to not do it by default. I.e. default behavior is to treat null as a valid value that is left untouched by default. And only convert it to n-u-l-l when specified in IDL. To answer your original question. I think the most important thing is to have few exceptions that authors have to learn. > It may actually be indicative of a need for two distinct types: strings > (i.e., possibly empty sequences of characters) and strings-or-null. But > I don't know if it's worth rewriting everything in this way. Yeah / Jonas
Re: [whatwg] [html5] Rendering of interactive content
On Sat, 7 Feb 2009, Giovanni Campagna wrote: > 2009/2/6 Ian Hickson > > On Fri, 6 Feb 2009, Giovanni Campagna wrote: > > > > > > I'm proposing to replace the current rendering mechanism, based on > > > Behavioural Extension to CSS, that in turn is based on XBL2, with > > > something based on the CSS3 Basic User Interface (css3-ui), ie > > > replacing the binding: property with appropriate appearance: > > > property directly on the element, instead of relying on the binding > > > itself. > > > > The two properties are orthogonal -- 'binding' sets the behavior, > > 'appearance' sets the look-and-feel. > I thought about it later, and I realized that you cannot style complex > widgets without XBL (or something like that) because pseudo-elements are > not reached by events. If they ever would, we would have horrible > situations we have now. > > So for complex widgets (Number, File, Slider) it may be impossible to > avoid a binding property, but anywhere it is possible you should try to > use the available (appearance, content, icon, etc.). Even when using > those, the author is able to shut them down, and knows perfectly which > of them apply (they're defined normatively in HTML5 and they're exposed > by browser tools for web dev). This allows for them to be selectively > disabled, eg. to show BB without a button but with the native icon. As far as I know I've only used 'binding' where it is necessary. Note that only uses the binding if it's not empty. > What is more important, is that appearance normatively defines what > properties from outside the appearance definition are allowed to > interfere with the native look of the widget, binding does not. If > author style sheets are not imported in XBL > (apply-author-sheets="false"), they don't apply at all. I'm not sure what you mean when you say 'binding' doesn't define this -- as far as I can tell, XBL2 fully defines what should happen here. We can't really know ahead of time whether the bindings should have apply-author-sheets="false" or "true", though. > > The advantage of appearance vs binding is that: > > > 1) you don't need an additional pass before applying the correct > > > platform-specific widget style > > > > With UA-native bindings, you wouldn't need an additional pass either. > > The current spec says "User agents are encouraged to make their bindings > set the 'appearance' CSS property appropriately to achieve > platform-native appearances for widgets": this means that the binding > should set appearance, and then appearance should make the widget look > like a normal button. I wouldn't characterise that as an extra pass, but ok. I don't think it's a problem. > > > 2) you depend on css3-ui, in CR stage, instead of becss, a very > > > early WD > > > > BECSS is actually probably more stable than CSS3 UI at this point. > > Why do you say so? Will CSS3 UI go back to Last Call or BECSS process to > Last Call in the near future? I'm not sure. In the mean time, CSS3 UI is > final, and waiting only for implementation. CSS3 UI is very vague, and is going to need serious work before browsers are able to actually implement it properly. A lot of the vendor feedback at the time it was written was dismissed (e.g. it doesn't have a particularly useful or comprehensive list of appearances). > > > 3) you don't block the binding property: I don't expect that > > > applying an XBL binding on an element causes it to appear like a > > > span (because it gets almost no default CSS) > > > > This is actually intentional. Experience with elements like > > that have styles that aren't expressed in CSS is that you end up not > > being able to restyle them properly if you desire. With 'binding' we'd > > be able to knock out the whole default rendering (including weird > > things with the children) in one go. > > The fact is that binding it the best way to apply a set of event > handlers to an element. Having to tweak the computed style of a fieldset > in order to find what properties are actually set and reproduce them in > the binding, just to put a set of onchange handlers to lots of fieldset, > does not look optimal. I don't understand why you would need to know what properties are set, or what 'onchange' has to do with anything here. > > > 4) you keep the appearance property working: current UA (Firefox and > > > Safari at least) already implement appearance, and correctly set it > > > on the input element. This could no longer be possible using XBL, > > > because of the CSS inheritance model inside XBL (if you apply to > > > appearance to some part of the shadow tree, it is not visible on the > > > bound element) > > > > I don't understand what you mean here. > > I mean that Firefox and Safari set the appearance property on the widget > element, and it is visible from outside, and dynamically changeable at > run time. The binding property instead contains an opaque and UA > specific value, that is
[whatwg] Author control over media preloading/buffering
When a media element loads, reaches the HAVE_CURRENT_DATA state, but is paused, and 'autoplay' is not set, we have to decide whether to keep downloading data or not. If we expect the user to play the stream, we should keep downloading and buffering data to minimize the chance that buffering will be needed during playback. But if we don't expect the user to play the stream, we should pause the download to conserve resources. The latter is especially important on pages with large numbers of media elements, only one or two of which the user will play. In general it's hard to see how to make a good guess automatically. If a page has one (non-autoplay) media element on it, it's hard to know whether the user is expected or not expected to play it. For example the user might be expected to play it, but only after they've read some text before the video (so autoplay is not appropriate). I think (but I'm not sure) that authors are likely to be able to make better guesses, so I think it would be useful to provide authors with control over this decision. I think that authors are likely to want this control in the same way they like to be able to preload images. So, how about adding an "autobuffer" attribute, which instructs the browser that the user will probably play the video and as much data as possible should be pre-downloaded? By default (when the attribute is not present) the browser would be expected to pause the download after reaching HAVE_CURRENT_DATA if the media element is paused and not 'autoplay'. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Color attributes
On Wed, 11 Feb 2009 01:22:59 +0100, Ian Hickson wrote: On Thu, 16 Oct 2008, Simon Pieters wrote: Color attributes in HTML have special processing. [...] It seems that some pages use three-digit notation and expect it to work as in CSS. I've made the algorithm do that and I've drafted up a spec for this: http://simon.html5.org/specs/html-color-attributes The spec now defines this. It seems the spec lacks the CSS2 system colors and 'transparent'. -- Simon Pieters Opera Software
