Re: [whatwg] link rel=icon width= height=aRe:
Ian Hickson wrote: Using media queries for this is serious overkill. I can easily imagine uses for this that are from code that doesn't have a media queries implementation available, and this isn't something that implementors are going to implement media queries for. We need a solution that is easy to adopt from the implementation point of view. Fair enough. That isn't to say that media queries shouldn't be allowed, though, and if people use them then they should work, if the UA supports them. Would it not be better to explitly say that media queries are not appropriate for this, for interoperability? I don't really agree with the premise that we somehow need to be frugal with attributes. We should use them when they are appropriate. Sure, we shouldn't waste them, but they're not a resource in scarce supply or that has some insane cost to them. Note that we already have a DOM attribute on link that is specific to one rel type, namely disabled. In fact, generic attributes are a pain in the neck. Consider title, whose behaviour changes radically if we're talking about rel=stylesheet versus something else. In general I agree that attributes are not a scarce resource, but if you need to add use-specific attributes to a supposedly-generic element I think that indicates that the generic element is inappropriate for the use-case. I don't know what link rel type uses disabled, but I would have had the same objection to that. If the meaning of title is something different for stylesheets than for other link rel types then that was an inappropriate use of that attribute as well. It's too late to change it now, but that's no reason to continue overloading generic elements/attributes with special cases. link is also interesting in that unlike input type=... rel can contain several values. Is it conforming to use width and height attributes on a link element that contains both icon and a another, non-icon keyword? What about a rel=icon ... width=... height=... ? Finally, what is the process for contributors to the RelExtensions page to include extension attributes? link rel=icon type=image/gif; width=24, height=24 href=... This doesn't really work because we would need to add parameters to types we might not yet know. It also results in potentially complicated parsing rules, which I don't think people would get right. (See the comments I made for media queries.) Presumably this would be defined (if at all) for everything under image/, just as charset is defined for everything under text/. (In theory, at least.)
Re: [whatwg] Text APIs on canvas
Ian Hickson wrote: On Wed, 7 May 2008, Tim Johansson wrote: On Tue, 06 May 2008 05:10:41 +0200, Ian Hickson [EMAIL PROTECTED] wrote: I have introduced the following APIs: context.font context.textAlign context.textBaseline context.fillText() context.strokeText() strokeText more or less requires a scalable font, which is not available in all fonts (and frequently not in mobile phones). I cannot see any comments on what should happen when the specified font is not capable of generating a stroke. I guess doing a fill instead is the only sensible thing to do (as the author has no way of knowing which fonts are available and/or scalable and it's bad if text disappears). Stroking text is complicated as it is generally less common to have support for it in the font library. I would prefer to see stroking removed from the spec as it will not work well with all fonts/devices. The idea is that only scalable (vector) fonts should be used, since otherwise things will quickly look ugly. I've made the spec require this. Going forward the spec is likely to require effects such as adding text to paths, which will require vector data for all fonts used anyway. I don't want to mislead implementators into thinking bitmap fonts are in any way an option in this day and age. The problem is that bitmap fonts flourish on handheld and devices and, as mentioned by others, in high density alphabets. With the Text APIs being a MUST, this can be a bugger. Apropos context.fillText() and the maxWidth attribute, the spec now says 4. If the maxWidth argument was specified and the hypothetical width of the inline box in the hypothetical line box is greater than maxWidth CSS pixels, then change font to have a more condensed font (if one is available or if a reasonably readable one can be synthesised by applying a horizontal scale factor to the font) or a smaller font, and return to the previous step. Scaling the glyphs uniformly, vertically anchored to the textBaseline, would look much more coherent and be more predictable for developers than applying a non-uniform scaling or changing the font altogether. If possible I would loose the part about changing the font or applying an horizontal scale factor to the font. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] link rel=icon width= height=aRe:
The integers should be separated by times; and not by x. In case you care about semantics, that is. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Thursday, May 08, 2008 4:18 AM To: WHATWG Subject: [whatwg] link rel=icon width= height=aRe: I've added a sizes attribute to link for the icon keyword. It takes a space separated list of keywords consisting of two integers separated by an x or the keyword any.
Re: [whatwg] Adding mouseenter and mouseleave events
I have recently developed an application to identify persons pointed at on a photograph. When person A stands in front of person B the inquirer moves from person A to person B, the application becomes unstable: exit A, enter B, exit B, enter A. It is rather annoying. The person behind should be ignored. Returning false from the handler does not help. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Thursday, May 08, 2008 2:56 AM To: Magnus Kristiansen Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Adding mouseenter and mouseleave events On Thu, 15 Mar 2007, Magnus Kristiansen wrote: Mouseover/out events will trigger when elements contained inside the EventTarget are hovered, and then bubble up. This is contrary to the most obvious interpretation, as you are still inside (over) the targeted element. IE supports two events, mouseenter[1] and mouseleave[2], which solve this problem by not bubbling. It is possible to work around the problem by using target/relatedTarget and walking up the DOM tree. However, this requires extra code for every event handler. Besides, these events were often not meant to be generated in the first place, by the intent of the author. I have no statistics for how often mouseover/out are used with and without intent of bubbling, but the anecdotal evidence from my own experience has never found me wanting it. I suggest these two events be added to the web applications spec. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseente r.asp [2] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseleav e.asp I recommend sending this feedback to the WebAPI working group, which is working on DOM events. (I shall forward the thread to the working group, but I do not know if the WebAPI working group has an effective issue tracking mechanism, so you may wish to follow this up to ensure that it gets handled.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SQL section feedback
I think it is safest not to replace the placeholders at all; the data server engine should accept queries with parameters (submitted separately). Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, May 07, 2008 7:15 AM To: WHATWG Mailing List Subject: [whatwg] SQL section feedback - 4.11.3 defines that placeholders simply have to be replaced with values from the arguments array. As I understand, this does not per se ban SQL injections. Will the spec define *how* to replace placeholders, including how to escape and quote values? Yeah, this will be defined when we define the SQL language subset. On Tue, 26 Feb 2008, Ralf Stoltze wrote: So step 3 Replace each ? placeholder can be skipped if the underlying DB architecture already has a similar mechanism. Well, the underlying DB architecture is part of the UA, so the UA is still doing step 3. I don't really care how. :-)
Re: [whatwg] A few editing suggestions for the HTML5 spec
The problem does not exist in German grammar because the infinitive is placed at the end. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Wednesday, May 07, 2008 7:03 AM To: Peter Kasting Cc: [EMAIL PROTECTED]; Geoffrey Garen; Ian Hickson Subject: Re: [whatwg] A few editing suggestions for the HTML5 spec On May 6, 2008, at 9:38 PM, Peter Kasting wrote: On Tue, May 6, 2008 at 6:44 PM, Ian Hickson [EMAIL PROTECTED] wrote: 8.2.1 do not have to actually create a DOM Document object do not actually have to create a DOM Document object (split infinitive) I prefer the split version. FWIW I prefer the non-split version as well. But I am a grammar Nazi :) In English grammar, the split infinitive is not an error. I wouldn't know about German grammar. Regards, Maciej
Re: [whatwg] Text APIs on canvas
Apple Macintosh, the GUI champion, uses condensed font. Lucida Grande is not considered a condensed font. -- Charles -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Krištof Želechovski Sent: Thursday, May 08, 2008 9:53 AM To: 'Mathieu HENRI'; [EMAIL PROTECTED] Subject: Re: [whatwg] Text APIs on canvas Making the font smaller would make line spacing non-uniform and the text could be hard to read. Apple Macintosh, the GUI champion, uses condensed font. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathieu HENRI Sent: Thursday, May 08, 2008 11:03 AM To: [EMAIL PROTECTED] Subject: Re: [whatwg] Text APIs on canvas Apropos context.fillText() and the maxWidth attribute, the spec now says 4. If the maxWidth argument was specified and the hypothetical width of the inline box in the hypothetical line box is greater than maxWidth CSS pixels, then change font to have a more condensed font (if one is available or if a reasonably readable one can be synthesised by applying a horizontal scale factor to the font) or a smaller font, and return to the previous step. Scaling the glyphs uniformly, vertically anchored to the textBaseline, would look much more coherent and be more predictable for developers than applying a non-uniform scaling or changing the font altogether. If possible I would loose the part about changing the font or applying an horizontal scale factor to the font. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Text APIs on canvas
I do not know about Lucida Grande, I stopped at Charcoal. Sad but true. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Sent: Thursday, May 08, 2008 7:03 PM To: [EMAIL PROTECTED] Subject: Re: [whatwg] Text APIs on canvas Apple Macintosh, the GUI champion, uses condensed font. Lucida Grande is not considered a condensed font. -- Charles
Re: [whatwg] link rel=icon width= height=aRe:
There's no need to request things more than once -- I base my editing decisions on the quality of the arguments put forward, not the quantity. By all means, if you have new information, bring it forward, but merely repeating what has already been said doesn't do anything. I'm sorry. I missed that there already was an image/*; width=...; height=... proposal. I saw only the image/*; sizes=... proposal. Won't happen again :)
Re: [whatwg] Script, style and backwards compatibility
On Mon, 30 Apr 2007, Simon Pieters wrote: From http://forums.whatwg.org/viewtopic.php?t=38 I can extract two requests. 1. Explain how authors are supposed to comment their script and style elements in HTML5. (Post #171.) Something along the following lines could be inserted as a note in the syntax section, e.g. after the CDATA elements can have text, ... paragraph: Old browsers that don't understand the style or script elements (introduced in HTML 3.2) will attempt render their contents. However, the strings !-- and -- are part of the CSS syntax, and !-- is equivalent to // in JavaScript, so authors who don't want to reveal their style sheets or scripts to users with such browsers can simply comment them out. [CSS21] [ECMA262] style !-- ... -- /style script !-- ... //-- /script (But it is an issue though that ECMAScript 262 still doesn't define the !-- magic.) Is there really any need to escape the contents of script/style at all these days? 2. Explain how HTML5 and XHTML5 differ in practice. (Post #187.) e.g. something like http://wiki.whatwg.org/wiki/HtmlVsXhtml could be included as a non-normative appendix to the spec, or referenced to in the HTML vs. XHTML section, or similar. I'd rather just leave this to non-normative documentation outside of the spec, if that's ok. It's easier to update things that aren't in the spec, and this is the kind of thing where we might well find things we've missed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Typo in UndoManager interface
On Sun, 17 Jun 2007, Samuel Weinig wrote: In the UndoManager interface there is a typo in the add() method. The title parameter should be a DOMString, not a DOMStrong. :) Thanks, fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Discussion on machine-checkability on public-html
On Fri, 6 Jul 2007, Henri Sivonen wrote: http://lists.w3.org/Archives/Public/public-html/2007Jun/0251.html http://lists.w3.org/Archives/Public/public-html/2007Jun/0252.html http://lists.w3.org/Archives/Public/public-html/2007Jun/0254.html http://lists.w3.org/Archives/Public/public-html/2007Jun/0256.html http://lists.w3.org/Archives/Public/public-html/2007Jun/0278.html As a summary of what might need changing in the spec, I highlight these paragraphs (from message 0256 above): A machine-checkable criterion should probably be defined to be a criterion the conformance to which is a decidable problem (in the computer science sense) given a document (Content-Type and finite byte stream) and the knowledge embodied in the spec and the normative references. That is, the program computing whether a given document conforms to a criterion should not be required to consult outside resources and should not embody arbitrary knowledge that isn't part of the spec (with normative references). I don't understand how the spec doesn't already say all this in the phrase machine-checkable. However, I also wrote: As a side note: For extra usefulness, a checker can have knowledge about particular URI scheme-specific requirements. Different choices here cause a theoretical problem. If we want to remove the theoretical problem, the spec could enumerate a closed list of URI schemes that conformance checkers must know about. (Forbidding the application of knowledge about common schemes like http, https and mailto would be silly.) I don't really see what the problem is here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Script, style and backwards compatibility
On Thu, May 8, 2008 at 11:43 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 30 Apr 2007, Simon Pieters wrote: From http://forums.whatwg.org/viewtopic.php?t=38 I can extract two requests. 1. Explain how authors are supposed to comment their script and style elements in HTML5. (Post #171.) Something along the following lines could be inserted as a note in the syntax section, e.g. after the CDATA elements can have text, ... paragraph: Old browsers that don't understand the style or script elements (introduced in HTML 3.2) will attempt render their contents. However, the strings !-- and -- are part of the CSS syntax, and !-- is equivalent to // in JavaScript, so authors who don't want to reveal their style sheets or scripts to users with such browsers can simply comment them out. [CSS21] [ECMA262] style !-- ... -- /style script !-- ... //-- /script (But it is an issue though that ECMAScript 262 still doesn't define the !-- magic.) Is there really any need to escape the contents of script/style at all these days? In order to validate a page as valid HTML/XHTML you need to escape inline script when using characters like . 2. Explain how HTML5 and XHTML5 differ in practice. (Post #187.) e.g. something like http://wiki.whatwg.org/wiki/HtmlVsXhtml could be included as a non-normative appendix to the spec, or referenced to in the HTML vs. XHTML section, or similar. I'd rather just leave this to non-normative documentation outside of the spec, if that's ok. It's easier to update things that aren't in the spec, and this is the kind of thing where we might well find things we've missed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Samuel Santos http://www.samaxes.com/
Re: [whatwg] link rel=icon width= height=
On Thu, 08 May 2008 03:17:38 +0100, Ian Hickson [EMAIL PROTECTED] wrote: I've added a sizes attribute to link for the icon keyword. The spec now contains: If multiple icons are provided, the user agent must select the most appropriate icon according to the media and sizes attributes. If there are multiple equally appropriate icons, user agents must use the first one declared in tree order. Does this disallow composing .ico files from multiple separate files? UAs like Fluid or Prism can't know which sizes OS is going to use, so all valid ico sizes are 'equally appropriate'. Also this algorithm doesn't match current browser behaviour, is this intentional? I did a quick test with a bunch of random favicons: * Opera 9.5b2 loads all icons (that's pretty bad if one decides to provide Leopard's monsterous 300KB icons) and displays last icon loaded, * Firefox 3b5 picks last icon regardless of attributes. It loads all icons when I reload page after restoring session. * WebKit nightly and Fluid pick last icon that has type attribute (even if type is bogus), or just last if none have type. I'm afraid that this could cause trouble (every visitor downloading icon that's 20–300 times larger than typical favicon). Why not use rel=application-icon or rel=appicon? I don't like the any keyword. SVG icons are scallable, but it's not the same as being usable at any size. For example Tango icons project provides PNG for 16, 22 and 32px icons in addition to SVG, because lines and finer details in SVG become illegible at small sizes. Does the specified size imply that UA is required to display icon at given size only? (i.e. is any obligatory to have icon scaled at all?) What if sizes attribute is absent? -- regards, Kornel Lesiński
Re: [whatwg] Script, style and backwards compatibility
On Fri, 09 May 2008 00:50:20 +0100, Samuel Santos [EMAIL PROTECTED] wrote: In order to validate a page as valid HTML/XHTML you need to escape inline script when using characters like . You can use: /*![CDATA[*/ /*]]*/ It's compatible with both HTML and XHTML. -- regards, Kornel Lesiński
[whatwg] link rel=icon sizes=? What if sizes is incorrect?
On further reflection, I'll concede that the style attribute is probably better suited to deciding what to do with the icon once it is fetched. Using it as metadata to decide what is fetched is problematic if multiple sizes are to be allowed to be specified in a single link element. However I do see some problems with the proposed sizes attribute. Mainly, I am troubled by the statement: The keywords specified on the sizes attribute must not represent icon sizes that are not actually available in the linked resource. No matter what the spec says, I think we can all agree that once this enters the real world there will be times when the icon size given is wrong. So what to do? At a minimum, I think the behavior called for when dealing with the type attribute is called for: User agents must not consider the type attribute authoritative — upon fetching the resource, user agents must not use metadata included in the link to the resource to determine its type. However once a mismatch is discovered, does that mean that the icon that has been retrieved should be scaled as if it were an img, or should the icon be discarded and the next icon which matches the available parameters be used instead?
Re: [whatwg] link rel=icon sizes=? What if sizes is incorrect?
On Thu, May 8, 2008 at 7:29 PM, Ernest Cline [EMAIL PROTECTED] wrote: No matter what the spec says, I think we can all agree that once this enters the real world there will be times when the icon size given is wrong. So what to do? At a minimum, I think the behavior called for when dealing with the type attribute is called for: User agents must not consider the type attribute authoritative — upon fetching the resource, user agents must not use metadata included in the link to the resource to determine its type. However once a mismatch is discovered, does that mean that the icon that has been retrieved should be scaled as if it were an img, or should the icon be discarded and the next icon which matches the available parameters be used instead? I agree that mismatches will occur in the real world. I think it can be left to the UA as to what to do in that case, as it is a developer mistake. In the case of Gears, what we would do is use the (possibly incorrect) icon the developer specified for the instant preview, and then use the correct sizes determined from actually downloading the images when we create the shortcut. - a
[whatwg] Couple of appendicies
On Thu, 12 Jul 2007, Smylers wrote: A very minor niggle with the 'Structure of this specification' section, which says: There are also a couple of appendices, defining shims for WYSIWYG editors, rendering rules for Web browsers, and listing areas that are out of scope for this specification. http://www.whatwg.org/specs/web-apps/current-work/#structure That's 3 appendicies, which is more than a couple. I removed one of those three. For what it's worth, editorial things like this usually solve themselves, either because the text is removed, or changed, or because (as in this case) something else changes to make it ok. I wouldn't bother reporting editorial things until we're basically done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
