Re: [whatwg] Selectors within

[David Hyatt]

On Jun 16, 2011, at 4:14 PM, Tab Atkins Jr. wrote:

> On Thu, Jun 16, 2011 at 1:48 PM, David Hyatt  wrote:
>> Do you actually mean try out both ":scope" tacked on to the end of the rule 
>> as well as ":scope " (note the space indicating a descendant selector) 
>> tacked on to the beginning?
>> 
>> So for example, #foo { } would turn into #foo:scope, :scope #foo { } thus 
>> allowing it to match either the scope or a descendant of the scope?
> 
> No, it's an if/else.  "#foo" would be equivalent to ":scope #foo".  On
> the other hand, "#foo :scope" would be unaltered.
> 
> ~TJ

So you're suggesting it would be impossible for a rule to match the scope 
itself without the author having to explicitly qualify it with :scope? That 
seems very unintuitive.

dave
(hy...@apple.com)

Re: [whatwg] Selectors within

[David Hyatt]

Do you actually mean try out both ":scope" tacked on to the end of the rule as 
well as ":scope " (note the space indicating a descendant selector) tacked on 
to the beginning?

So for example, #foo { } would turn into #foo:scope, :scope #foo { } thus 
allowing it to match either the scope or a descendant of the scope?

This would also have the benefit of allowing you to cross if the rightmost 
selector in a chain is the scope without having to explicitly use :scope.

For example:

#outsideScope #insideScope { }

would turn into

#outsideScope #insideScope:scope, :scope #outsideScope #insideScope { }

thus allowing crossing for the case where #insideScope is the scope itself.

dave
(hy...@apple.com)

On Jun 16, 2011, at 1:32 PM, Dimitri Glazkov wrote:

> What if we do this:
> 
> 1) By default, 

Re: [whatwg] style sheet blocking scripts

[David Hyatt]

It is considered a bug.

On Dec 9, 2009, at 4:57 PM, Jonas Sicking wrote:

> On Wed, Dec 9, 2009 at 2:10 PM, James Robinson  wrote:
>> 2009/12/9 tali garsiel 
>>> 
>>> Well, not completely.
>>> Regarding the first question- Webkit guys told me (on their IRC channel)
>>> that the don't block the parser and only block scripts that request visual
>>> information, so I'm still  confused.
>> 
>> Here's my understanding of the implementation inside WebKit currently:
>> During parsing, WebKit does not block the parser on stylesheet loads, but
>> does block external scripts from running until previously-encountered
>> stylesheets have loaded.  WebKit does not suspend script execution on
>> requests for visual information if stylesheets have not loaded (for example
>> for inline scripts or in the case of stylesheets added dynamically after
>> parsing has completed).  WebKit does suspend parsing of the document on
>> script loads, but has a speculative preloader to attempt to start fetches
>> for resources past the 

Re: [whatwg] style sheet blocking scripts

[David Hyatt]

On Dec 9, 2009, at 4:10 PM, James Robinson wrote:

> 2009/12/9 tali garsiel 
> Well, not completely.
> Regarding the first question- Webkit guys told me (on their IRC channel) that 
> the don't block the parser and only block scripts that request visual 
> information, so I'm still  confused.
> 
> Here's my understanding of the implementation inside WebKit currently:
> During parsing, WebKit does not block the parser on stylesheet loads, but 
> does block external scripts from running until previously-encountered 
> stylesheets have loaded.  WebKit does not suspend script execution on 
> requests for visual information if stylesheets have not loaded (for example 
> for inline scripts or in the case of stylesheets added dynamically after 
> parsing has completed).  WebKit does suspend parsing of the document on 
> script loads, but has a speculative preloader to attempt to start fetches for 
> resources past the 

Re: [whatwg] style sheet blocking scripts

[David Hyatt]

This is false.  WebKit will block the parser when it encounters an external 
script if there are pending stylesheet loads.  However we have a speculative 
preloader that will continue to parse and load resources beyond that script 
(but the real parser will be blocked).

dave

On Dec 9, 2009, at 3:42 PM, tali garsiel wrote:

> Well, not completely.
> Regarding the first question- Webkit guys told me (on their IRC channel) that 
> the don't block the parser and only block scripts that request visual 
> information, so I'm still  confused.
> 
> > Date: Wed, 9 Dec 2009 17:01:30 +
> > From: i...@hixie.ch
> > To: t_gars...@hotmail.com; bzbar...@mit.edu
> > CC: wha...@whatwg.org
> > Subject: Re: [whatwg] style sheet blocking scripts
> > 
> > On Wed, 28 Oct 2009, tali garsiel wrote:
> > > 
> > > This is a quote from Section 4.2 of the spec:
> > > 
> > > "A style sheet in the context of the Document of an HTML parser or XML 
> > > parser is said to be a style sheet blocking scripts if the element was 
> > > created by that Document's parser, and the element is either a style 
> > > element or a link element that was an external resource link that 
> > > contributes to the styling processing model when the element was c reated 
> > > by the parser, and the element's style sheet was enabled when the 
> > > element was created by the parser, and the element's style sheet ready 
> > > flag is not yet set, and, the last time the event loop reached step 1, 
> > > the element was in that Document"
> > > 
> > > And the section about parsing - the "

Re: [whatwg] video background color (Was: Interpretation of video poster attribute)

[David Hyatt]

I agree.

dave

On Jun 19, 2008, at 8:05 AM, Philip Jägenstedt wrote:


Safari already uses a transparent background by default and to me that
doesn't seem like a bad idea -- it may be best to hide small 1px
letterboxes due to rounding errors in aspect ratio calculation etc.
Setting "background-color:transparent" to override the default black  
is

probably less known to most authors and transparent background is also
more in line with most other HTML elements.

I would suggest eventually specifying this behavior in the rendering
section, unless someone feels that default black letterboxes is very
important.

// Philip

On Fri, 2008-06-13 at 21:02 +, Ian Hickson wrote:

On Fri, 13 Jun 2008, Philip Jgenstedt wrote:


The issue with the poster attribute is resolved, but one comment  
made me

remember something I've wondered about:

On Fri, 2008-06-13 at 09:26 +, Ian Hickson wrote:

It's not impossible; first black would render 300x150, then the  
poster


The spec says: Areas of the element's playback area that do not  
contain

the video represent nothing.

What does this mean? Black is customary for video, but leaving the
region transparent (thus falling back to css background color) is
another option. Which is better?


It's transparent, but I intended to have the following rule in the  
style

sheet:

  video { background: black; }

...so that it looks black unless the author restyles it. Does that  
make

sense?

--
Ian Hickson   U+1047E) 
\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _ 
\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'-- 
(,_..'`-.;.'

--
Philip Jägenstedt
Opera Software

Re: [whatwg] [canvas] imageRenderingQuality property

[David Hyatt]

On Jun 2, 2008, at 4:57 PM, Vladimir Vukicevic wrote:



On Jun 2, 2008, at 2:39 PM, Oliver Hunt wrote:
That's exactly what i would be afraid of people doing.  If I have a  
fast system why should i have to experience low quality rendering?   
It should be the job of the platform to determine what level of  
performance or quality can be achieved on a given device.   
Typically such a property would be considered a "hint", and as such  
would likely be ignored.


If honouring this property was _required_ rather than being a hint  
you would hit the following problems:
* Low power devices would have a significant potential for poor  
performance if a developer found that their desktop performed well  
so set the requirement to high quality.
* High power devices would be forced to use low quality rendering  
modes when perfectly capable of providing better quality without  
significant performance penalty.
Neither of these apply if the property were just a hint, but now  
you have to think about what happens to content that uses this  
property in 18 months time.  You've told the UA to use a low  
quality rendering when it may no longer be necessary, so now the UA  
has a choice it either always obeys the property meaning lower  
quality than is necessary so that new content performs well, or it  
ignores the property in which case new content performs badly.


If web apps misuse the property, then bugs should be filed on those  
apps that incorrectly use the property, and the app developer should  
fix them.  The web platform shouldn't prevent developers from  
exercising control over how their content is rendered; most  
developers, as you say, probably shouldn't change anything from the  
default 'auto'.  But the capability should be there.  Arbitrarily  
deciding what developers can and can't do isn't interesting from the  
perspective of creating a full-featured platform, IMO.


No matter how fast smooth/bilinear filtering is, something more  
complex is always going to be slower, and something less complex is  
always going to be faster.  If those perf differences are  
significant to the web app, no matter how small, you're going to  
want to be able to have that control.  If they're not, then you  
should just be using 'auto' and let the UA handle it.


I completely agree.  Almost any feature can be abused.  It's not our  
job to withhold features just because they can be abused.  It's also  
worth pointing out that this is a common graphical knob supported by  
Cairo and CoreGraphics.  It is a proprietary MS CSS property and an  
SVG CSS property.  In other words, it seems to be a pretty widely  
implemented feature and as such seems like it would be a worthwhile  
addition to canvas.


If we add this, we should also add support for text rendering quality  
as well, since canvas is picking up the ability to draw text.


dave
([EMAIL PROTECTED])

Re: [whatwg] [canvas] imageRenderingQuality property

[David Hyatt]

On Jun 2, 2008, at 4:34 PM, Vladimir Vukicevic wrote:

Yeah, I agree -- I thought that there was some plan somewhere to  
uplift a bunch of these SVG CSS properties into general usage?  I  
know that Gecko uplifted text-rendering, we should figure out what  
else makes sense to pull up.  (If image-rendering were uplifted, it  
would apply to , for the scaling/transformation of the  
canvas element itself as opposed to the canvas rendering content.)


   - Vlad


Right, that would be my expectation as well (that the CSS property  
could be applied to  to control the quality when rendering the  
canvas buffer itself).


dave

Re: [whatwg] [canvas] imageRenderingQuality property

[David Hyatt]

I like the idea of this property.  I actually would love to see the  
SVG property applied to HTML  as well. :)


dave

On Jun 2, 2008, at 4:15 PM, Vladimir Vukicevic wrote:



Sure; bilinear filtering is slower than nearest neighbour sampling,  
and in many cases the app author would like to be able to decide  
that tradeoff (or, at least, to be able to say "I want this to go as  
fast as possible, regardless of quality").  Some apps might also  
render to a canvas just once, and would prefer to do it at the  
highest quality filtering available even if it's more expensive than  
the default.


   - Vlad

On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote:
Um, could you actually give some kind of reasoning for these?  I am  
not aware of any significant performance issues in Canvas that  
cannot be almost directly attributed to JavaScript itself rather  
than the canvas.


--Oliver

On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:



I'd like to propose adding an imageRenderingQuality property on  
the canvas 2D context to allow authors to choose speed vs. quality  
when rendering images (especially transformed ones).  This is  
modeled on the SVG image-rendering property, at http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty 
:


attribute string imageRenderingQuality;

'auto' (default): The user agent shall make appropriate tradeoffs  
to balance speed and quality, but quality shall be given more  
importance than speed.


'optimizeQuality': Emphasize quality over rendering speed.

'optimizeSpeed': Emphasize speed over rendering quality.

No specific image sampling algorithm is specified for any of these  
properties, with the exception that, at a minimum, nearest- 
neighbour resampling should be used.  One alternative is to  
specify 'best', 'good', 'fast', with "good" being the default, as  
opposed to the SVG names; I think those names are more  
descriptive, but there might be value in keeping the names  
consistent with SVG, especially if that property bubbles up into  
general CSS usage.


 - Vlad

Re: [whatwg] Removal of Ogg is *preposterous*

[David Hyatt]

Also as Maciej said earlier, we at Apple did not ask that the SHOULD  
wording be removed and had stated we could live with it.


dave

On Dec 12, 2007, at 1:12 PM, David Hyatt wrote:


On Dec 12, 2007, at 6:38 AM, Elliotte Rusty Harold wrote:


David Hyatt wrote:

Fear of submarine patents is only one reason Apple is not  
interested in Theora.  There are several other reasons.  H.264 is  
a technically superior solution to Theora.  Ignoring IP issues,  
there would be no reason to pick Theora over H.264.  Everyone  
wants an open freely implementable codec, but it doesn't follow  
that Theora should automatically be that codec.  About the only  
argument I've heard in favor of Theora is that "it's open", but  
that is an argument based purely on IP and not on technical merits.


Openness is a prerequisite. Technical adequacy is a prerequisite.  
The technically best solution is not a prerequisite. In case it  
isn't obvious yet, an open, adequate format is preferred over a  
better proprietary one.




I don't think that is obvious at all, especially when the   
tag's chief competition, Flash, is using the technically superior  
solution.  Why would authors switch away from Flash if   
doesn't offer any technically compelling reason to switch?




If you consider mobile devices that want to browse the Web, then  
depending on the constraints of the device, a hardware solution  
may be required to view video with any kind of reasonable  
performance.  A mandate of Theora is effectively dictating to  
those mobile vendors that they have to create custom hardware that  
can play back Theora video.  Given that such devices may already  
need a hardware solution for existing video like H.264, it seems  
unreasonable for HTML5 to mandate what hardware a vendor has to  
develop just to browse Web video on a mobile device.


Thanks. I wasn't previously convinced we needed to mandate *any*  
particular format, but you just convinced me. If hardware is  
support is required for some devices, then it does indeed sound  
like a good idea to mandate some minimum level of conformance. It  
is far better that this minimum level of conformance be an open,  
freely implementable standard such as Ogg/Theora than a known  
patent encumbered format such as H.264.




Good.  I also believe there should be a mandated baseline.  That's  
why I think SHOULD is too weak, and that we should be working  
towards a MUST.


Or put another way, imagine that GIF was an open format but PNG  
was IP-encumbered.  Would you really want to limit the Web to  
displaying only GIFs just because it was the only open image  
format available?


Please stop attacking straw men. No one has suggested that. Under  
those circumstances, I absolutely would support requiring all  
browsers to display GIFs. This would not prohibit them from also  
displaying PNGs if they chose to license the relevant patents.




Right, but, continuing the analogy, the issue you run into is if the  
Web at large considers PNG to be superior and just ends up using it  
anyway, then specifying "SHOULD use GIF" is rather irrelevant.  I do  
not think people will switch to  using Theora when a  
technically superior alternative exists that will also work in  
Internet Explorer (Flash).  We have to make sure that  is on  
par technically with what Flash can do.


Technical arguments are relevant here, so take some time to  
consider them before accusing people of having shady ulterior  
motives.


Technical arguments are relevant, but do not control. They are  
neither the only nor the most important consideration.


Similarly an inadequate open standard should not be proposed as the  
only way forward simply by virtue of its openness.  Wanting an open  
standard does not mean that Theora should just be automatically  
chosen to be that open standard.  It is also a logical error to  
assume that openness is not desired by a vendor merely because one  
potential open format is not approved by that vendor.


dave
([EMAIL PROTECTED])

Re: [whatwg] Removal of Ogg is *preposterous*

[David Hyatt]

On Dec 12, 2007, at 6:38 AM, Elliotte Rusty Harold wrote:


David Hyatt wrote:

Fear of submarine patents is only one reason Apple is not  
interested in Theora.  There are several other reasons.  H.264 is a  
technically superior solution to Theora.  Ignoring IP issues, there  
would be no reason to pick Theora over H.264.  Everyone wants an  
open freely implementable codec, but it doesn't follow that Theora  
should automatically be that codec.  About the only argument I've  
heard in favor of Theora is that "it's open", but that is an  
argument based purely on IP and not on technical merits.


Openness is a prerequisite. Technical adequacy is a prerequisite.  
The technically best solution is not a prerequisite. In case it  
isn't obvious yet, an open, adequate format is preferred over a  
better proprietary one.




I don't think that is obvious at all, especially when the   
tag's chief competition, Flash, is using the technically superior  
solution.  Why would authors switch away from Flash if  doesn't  
offer any technically compelling reason to switch?




If you consider mobile devices that want to browse the Web, then  
depending on the constraints of the device, a hardware solution may  
be required to view video with any kind of reasonable performance.   
A mandate of Theora is effectively dictating to those mobile  
vendors that they have to create custom hardware that can play back  
Theora video.  Given that such devices may already need a hardware  
solution for existing video like H.264, it seems unreasonable for  
HTML5 to mandate what hardware a vendor has to develop just to  
browse Web video on a mobile device.


Thanks. I wasn't previously convinced we needed to mandate *any*  
particular format, but you just convinced me. If hardware is support  
is required for some devices, then it does indeed sound like a good  
idea to mandate some minimum level of conformance. It is far better  
that this minimum level of conformance be an open, freely  
implementable standard such as Ogg/Theora than a known patent  
encumbered format such as H.264.




Good.  I also believe there should be a mandated baseline.  That's why  
I think SHOULD is too weak, and that we should be working towards a  
MUST.


Or put another way, imagine that GIF was an open format but PNG was  
IP-encumbered.  Would you really want to limit the Web to  
displaying only GIFs just because it was the only open image format  
available?


Please stop attacking straw men. No one has suggested that. Under  
those circumstances, I absolutely would support requiring all  
browsers to display GIFs. This would not prohibit them from also  
displaying PNGs if they chose to license the relevant patents.




Right, but, continuing the analogy, the issue you run into is if the  
Web at large considers PNG to be superior and just ends up using it  
anyway, then specifying "SHOULD use GIF" is rather irrelevant.  I do  
not think people will switch to  using Theora when a  
technically superior alternative exists that will also work in  
Internet Explorer (Flash).  We have to make sure that  is on  
par technically with what Flash can do.


Technical arguments are relevant here, so take some time to  
consider them before accusing people of having shady ulterior  
motives.


Technical arguments are relevant, but do not control. They are  
neither the only nor the most important consideration.


Similarly an inadequate open standard should not be proposed as the  
only way forward simply by virtue of its openness.  Wanting an open  
standard does not mean that Theora should just be automatically chosen  
to be that open standard.  It is also a logical error to assume that  
openness is not desired by a vendor merely because one potential open  
format is not approved by that vendor.


dave
([EMAIL PROTECTED])

Re: [whatwg] Removal of Ogg is *preposterous*

[David Hyatt]

SHOULD is toothless.  It carries absolutely no weight.  I don't think  
it's appropriate for such weak language to be in the HTML5 spec.  It  
should either be a MUST (which is inappropriate at this juncture for  
reasons that Dave Singer. Ian Hickson and myself have posted about in  
previous messages) or just not be mentioned at all.


dave
([EMAIL PROTECTED])

On Dec 11, 2007, at 5:48 PM, Manuel Amador (Rudd-O) wrote:


Maybe you should take some time to read the previous discussions of
this issue before making such inflammatory accusations.


What accusation, David?  That Apple would prefer people not use Ogg  
to author
Web content, for reasons which are purely monetary in nature?  I  
only wrapped

it in humor!



Fear of submarine patents is only one reason Apple is not interested
in Theora.  There are several other reasons.  H.264 is a technically
superior solution to Theora.


This is unarguably TRUE.


Ignoring IP issues, there would be no
reason to pick Theora over H.264.  Everyone wants an open freely
implementable codec, but it doesn't follow that Theora should
automatically be that codec.


Agreed.  That's also why the standard didn't say MUST.  It said  
SHOULD.



About the only argument I've heard in
favor of Theora is that "it's open", but that is an argument based
purely on IP and not on technical merits.


However, I can make a pretty compelling case showing that Vorbis is  
at least

on par in performance with AAC.  So at least for Vorbis, it's not just
freedom but actual results.


If you consider mobile devices that want to browse the Web, then
depending on the constraints of the device, a hardware solution may  
be

required to view video with any kind of reasonable performance.  A
mandate of Theora is effectively dictating to those mobile vendors
that they have to create custom hardware that can play back Theora
video.  Given that such devices may already need a hardware solution
for existing video like H.264, it seems unreasonable for HTML5 to
mandate what hardware a vendor has to develop just to browse Web  
video

on a mobile device.


You are writing a very lengthy paragraph founded on a lie.  Where  
did the
standard mandate that Theora be required for conformance?  Because I  
read

SHOULD, not MUST.  And everyone's gonna be *years* until they're up to
MUST-level conformance to be concerned about the cost of hardware  
(Moore

helps here).

Or put another way, imagine that GIF was an open format but PNG was  
IP-
encumbered.  Would you really want to limit the Web to displaying  
only

GIFs just because it was the only open image format available?


What a way to build a strawman!  Who or where says that the Web is  
going to be
limited to Theora?  It says SHOULD, man, SHOULD.  You're free to use  
H.264 if
you want, and I'm pretty sure that your devices will still sell like  
crack on

the street.


Technical arguments are relevant here, so take some time to consider
them before accusing people of having shady ulterior motives.


In fact, I honestly wish there were only technical arguments to be  
made.  This

discussion would be much, much simpler.



dave
([EMAIL PROTECTED])




--

Manuel Amador (Rudd-O) <[EMAIL PROTECTED]>
Rudd-O.com - http://rudd-o.com/
GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/

You will not be elected to public office this year.

Re: [whatwg] Removal of Ogg is *preposterous*

[David Hyatt]

On Dec 11, 2007, at 3:46 PM, Manuel Amador (Rudd-O) wrote:

Apple and Nokia seem to think that there *are* hamburgers in the  
moon, and

that those hamburgers will cost them billions of dollars in submarine
sandwich lawsuits.

Of course, that's what they are *saying*.  It doesn't take a Feynman  
or a
Chomsky to understand the real reason why they want the Ogg  
hamburger off

HTML5.


Maybe you should take some time to read the previous discussions of  
this issue before making such inflammatory accusations.


Fear of submarine patents is only one reason Apple is not interested  
in Theora.  There are several other reasons.  H.264 is a technically  
superior solution to Theora.  Ignoring IP issues, there would be no  
reason to pick Theora over H.264.  Everyone wants an open freely  
implementable codec, but it doesn't follow that Theora should  
automatically be that codec.  About the only argument I've heard in  
favor of Theora is that "it's open", but that is an argument based  
purely on IP and not on technical merits.


If you consider mobile devices that want to browse the Web, then  
depending on the constraints of the device, a hardware solution may be  
required to view video with any kind of reasonable performance.  A  
mandate of Theora is effectively dictating to those mobile vendors  
that they have to create custom hardware that can play back Theora  
video.  Given that such devices may already need a hardware solution  
for existing video like H.264, it seems unreasonable for HTML5 to  
mandate what hardware a vendor has to develop just to browse Web video  
on a mobile device.


Or put another way, imagine that GIF was an open format but PNG was IP- 
encumbered.  Would you really want to limit the Web to displaying only  
GIFs just because it was the only open image format available?   
Technical arguments are relevant here, so take some time to consider  
them before accusing people of having shady ulterior motives.


dave
([EMAIL PROTECTED])

Re: [whatwg] More comments and questions on Web Apps 1.0

[David Hyatt]

I can give you my opinions.  Not sure if they match up with Ian's or  
not. :)


On Jun 6, 2007, at 2:41 AM, Henri Sivonen wrote:



 * When the data source was initialized from the DOM, will changes  
to the datagrid be reflected back to the DOM?


I would expect a DOM data source to be updated.

 * Is the datagrid a replaced element for the purposes of CSS or  
tree of anonymous/generated boxes?


Yes, I would expect that it would be a replaced element (just like  
 listboxes).


 * What parts (if any) are expected to map to native widgets in  
Cocoa/Win32/GTK+?


I would expect a data grid to look like an NSOutlineView on Mac.

 * Is datagrid useful for any purpose without scripting? If yes,  
please give an example.


Sure.  It's useful in form submission just as a listbox would be.


 * What is datagrid expected to look like in visual UAs?


The platform's native multi-column tree widget.

 * Is datagrid rendering expected to have pixel-consistent metrics  
across visual UAs?




No.  Mac would use Lucida Grande for the font, use NSOutlineView  
defaults for rows, etc.  Windows might use a tree with grid lines  
(and +/- signs like Explorer), etc.


dave
([EMAIL PROTECTED])

Re: [whatwg] should be allowed in

[David Hyatt]

We'd have to decide if  reopens across closures of .

dave

On May 29, 2007, at 3:57 PM, Anne van Kesteren wrote:

On Wed, 30 May 2007 00:11:22 +0200, David Hyatt <[EMAIL PROTECTED]>  
wrote:

WinIE allows it, and we just changed WebKit to allow it too.


So what exactly do you do when scripting is _disabled_ in this  
case? For instance with  or noscript>?



--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

[whatwg] should be allowed in

[David Hyatt]

WinIE allows it, and we just changed WebKit to allow it too.

dave

Re: [whatwg]

[David Hyatt]

If  were to be standardized, Apple would need this  
done in a way that would be backwards-compatible with our current  
syntax.  Otherwise we'd be forced to require an opt-in mode for HTML5  
(and that is really not something we want to have to do).


dave
([EMAIL PROTECTED])

On May 17, 2007, at 11:53 PM, Matthew Paul Thomas wrote:


On May 18, 2007, at 12:43 PM, Lachlan Hunt wrote:

...
* class="search"

The aim of this one was to be able to indicate the form  
specifically used for searching. This would then allow UAs,  
especially assistive technology, to implement keyboard shortcuts  
or other mechanisms for taking the user directly to the search  
form.  role="search" is provided by the role attribute spec for a  
similar purpose, and Safari also has .  I  
would prefer the new input type because it also has direct  
benefits for regular users, not just those with assistive technology.

...


I agree, why not add ? The use cases are:
*   Better accessibility, as described above by Lachlan.
*   People often scan Web pages looking for "the little box where I  
can
type".  If site  
search
fields were visibly different from other text fields, and  
different
*in a consistent way across sites*, that would make people  
faster at

using those sites.

There are also ill effects from it *not* being standardized. Web  
authors often use brittle CSS in an attempt to emulate the Mac OS X  
or Windows Vista search field look.



 (see the top of the page)
They're brittle in the sense that they have cosmetic differences  
from the native controls, they sometimes rely on JavaScript, they  
fall apart when the page is zoomed, and/or they don't zoom at all.  
(Safari's implementation in 1.3/2.0 also doesn't zoom, but that  
could be fixed much more easily in WebKit -- if it hasn't been  
already -- than in a CSS+PNG+JS imitation.)


I can think of one potential problem, that being Web authors trying  
to use  for fields that aren't search fields  
because they think it looks cool (and because they don't use  
assistive aids themselves, so they don't realize the silliness).  
That problem would be inversely proportional to how much browsers  
made the field behave unalterably like a search field.




* class="error"

The original idea for this was for indicating error messages,  
particularly related form fields.  The problem is that screen  
readers, when in forms mode, only read the content of form control  
labels, which has resulted in authors having to write any error  
messages within labels, which is kind of a hack.  Labels and error  
messages should be able to be separated and providing a way to  
specifically indicate them would allow screen readers to indicate  
their presence to the user and read it on request.

...


Maybe that should be addressed (in Web Forms 3?) with a specific  
 element.


Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/

Re: [whatwg] Saying +1 or -1 is not useful on this mailing list

[David Hyatt]

+1.  Agree with Hixie.

(ducks)

On Apr 30, 2007, at 1:19 PM, Ian Hickson wrote:


On Sat, 28 Apr 2007, mozer wrote:


+1


On Sat, 28 Apr 2007, David Hyatt wrote:


+1 also.


Please don't send e-mails with just "+1" (or "-1") to this mailing  
list.
While I know it seems to have become common practice in the public- 
html
mailing list, it will have absolutely no effect on this list (the  
WHATWG
list). I only consider the quality of arguments in making decisions  
for

the WHATWG spec, not the quantity. There could be 50 +1s asking for
something, and it would still only take one counterargument showing  
why

the request is bad to change the spec the other way.

Thanks,
--
Ian Hickson   U+1047E) 
\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _ 
\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'-- 
(,_..'`-.;.'

Re: [whatwg] classList.toggle()

[David Hyatt]

+1 also.

On Apr 28, 2007, at 3:49 AM, mozer wrote:


+1

On 4/28/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:




How about about adding a toggle() operation to classList? Adds the  
token if
not present, removes it if present. This would be useful for  
script code

that dynamically manipulates classes to cause style changes.

Regards,
Macie

Re: [whatwg] Drag'n'drop uploads propsal

[David Hyatt]

I am not sure that should be left up to some unspecified heuristic  
though.  There's also the issue of wanting to display a dropped file  
at the correct position within the DOM.


I like the idea of having a way of associating a file upload control  
with a contenteditable region and I also like the idea of having some  
way for the dropped resources associated with the control to display  
in the page.  The use case of being able to drop images into a  
contenteditable region and have them show up as  elements at the  
appropriate place and then get automatically uploaded somewhere is a  
really compelling one.


dave

On Apr 25, 2007, at 4:15 PM, Ian Hickson wrote:


On Thu, 26 Apr 2007, Kornel Lesinski wrote:


I've added proposal for drag'n'drop uploads to WHATWG Wiki.

http://wiki.whatwg.org/wiki/Drag'n'Drop_Uploads


 already supports this; user agents could easily just
make drags of files into the content area automatically be sent to the
nearest (likely only)  element. This is really just a
matter of getting the browser vendors to implement that UI.

--
Ian Hickson   U+1047E) 
\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _ 
\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'-- 
(,_..'`-.;.'

Re: [whatwg] on codecs in a 'video' tag.

[David Hyatt]

I agree with this.  The tag isn't worth much to the Web if it's not  
interoperable among *all* Web browsers.  That includes,  
unfortunately, Internet Explorer.  That is why I think trying to pick  
a baseline format in the WhatWG is premature.  Until the   
element moves to the HTML WG and we find out what Microsoft's opinion  
is on this subject, I'm not really sure what the point is of this  
codec debate.  Even if the browser vendors of the WhatWG all agreed  
to support Theora tomorrow, Mozilla + Opera + Safari constitute only  
20% of total browser market share.


That percentage is not even remotely compelling enough for content  
authors to want to use the  element over proprietary  
alternatives like Flash.


dave
([EMAIL PROTECTED])

 seems On Apr 3, 2007, at 9:50 PM, Håkon Wium Lie wrote:


Seriously, though, I think this group is concerned that having a
polished  interface isn't worth much in terms of
interoperability unless there is a baseline format.

[whatwg] Web Applications 1.0 Draft

[David Hyatt]

Posting this forwarded message regarding .

dave
([EMAIL PROTECTED])

==

Dear WHATWG and Mr. Hickson,

Apple Computer, Inc. (“Apple”) believes it has intellectual property  
rights
(“IP Rights”) relative to WHATWG’s Web Applications 1.0 Working  
Draft, dated
March 24, 2005, Section 10.1, entitled “Graphics:  The bitmap  
canvas”.   At

this time, Apple reserves all rights in its IP Rights and makes no
representations as to Apple’s willingness or unwillingness to license  
these

IP Rights.  However, in the event that the Web Applications 1.0 Working
Draft, dated March 24, 2005, becomes part of a formalized draft  
standard at

W3C or IETF, for example, Apple is prepared to address the
disclosure/licensing rules of such organizations.

Any questions regarding this communication should be directed to:

Director of Patents
Apple Computer, Inc.
1 Infinite Loop, MS 3-PAT
Cupertino, CA 95014-2084
Voice: (408) 974-9453
Fax:  (408) 974-5436
E-mail: [EMAIL PROTECTED]


Sincerely,

Helene Plotka Workman
Senior Patent Counsel, Apple Computer, Inc.

Re: [whatwg] Multi-touch events

[David Hyatt]

I'll have much more to say about this in the coming months.

dave
([EMAIL PROTECTED])

On Jan 30, 2007, at 11:44 PM, Rowan Nairn wrote:


Hi, I'm new to the list so I'm not sure if this is beyond scope or not
but has anybody thought about what kind of mouse events we would like
to get, say the iPhone (or similar) passes all the touches on to the
DOM?

I'm thinking the minimal helpful API change would be a new field for
the Event object that uniquely identifies a "pointing device" for the
duration of a mousedown-mousemove-mouseup cycle.

Any thoughts?  Some more of mine here:
http://eurekaman.com/towards-multi-touch-in-the-browser

Rowan

Re: [whatwg] markup as authored in practice

[David Hyatt]

Shipping Safari has no SVG support.  WebKit nightlies do.  That's the  
only reason the logo now renders correctly in the nightlies  so  
that particular file is completely irrelevant to this discussion.


dave

On Dec 2, 2006, at 2:41 PM, Robert Sayre wrote:


On 12/2/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
On Sat, 02 Dec 2006 22:55:00 +0100, Robert Sayre  
<[EMAIL PROTECTED]> wrote:


> On 12/2/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
>>
>> There's probably no way you can serialize that document.
>
> Hmm, Sam's example displayed correctly in Safari, Firefox,  
Opera, and

> recent WebKit nightlies.

Yes. Rendering it is different from serializing it though. I agree  
that it

has to work as it does.


What is the benefit of refusing to specify a serialization?



I'm not sure I see the relation to HTML5.


It's not conclusive, but the fact that



rendered correctly in WebKit nightlies while



regressed (in several different ways depending on the revision) is a
sign that the two ways of serving (X)HTML have more in common than the
HTML5 specification claims.

I don't understand why it's useful to pretend those pages live on
separate planets because they  have different MIME types. It is
already necessary to process XML and HTML5 simultaneously in order to
process syndication feeds, and all current browsers do that reasonably
well.

--

Robert Sayre

Re: [whatwg] Canvas lack of drawString method

[David Hyatt]

Yeah I see what you mean.  In addition to a drawText you probably  
want something like a metricsForText API that would tell you the  
extent of the string and the font metrics (line height, ascent,  
descent, baseline).


dave

On Oct 25, 2006, at 3:10 AM, James Graham wrote:


David Hyatt wrote:
I'm very reluctant to expose font metrics and information (yet).   
I think once you start getting into specifying fonts, you open up  
a can of worms that would make this sort of API addition a lot  
harder.


I still believe that any api that does not allow the author to  
query the size of the text bounding-box[1], i.e. the overall width  
and height of the box enclosing the text fragment, is useless for  
many of the use cases presented so far e.g. figure labelling as,  
without this information, it is impossible to ensure that adjacent  
text fragments do not overlap.


[1] I mean that in a non-technical sense

--
"Eternity's a terrible thought. I mean, where's it all going to end?"
 -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Re: [whatwg] Canvas lack of drawString method

[David Hyatt]

I'm very reluctant to expose font metrics and information (yet).  I  
think once you start getting into specifying fonts, you open up a can  
of worms that would make this sort of API addition a lot harder.


dave

On Oct 24, 2006, at 4:05 PM, Stefan Haustein wrote:


Hi David,

I think it is very important to be able to determine the rendered  
size of the text. Otherwise, there is no reliable way to make sure  
things do not overlap. Also, some kinds of applications (flash-like  
effects, labels expressing weight or distance, WYSIWYG text  
editors) may require variable font sizes or styles.


What do you think about

context.textStyle = "barchart"; // style by reference

context.textStyle = {  // set style directly
 "font-size": "8px",
 "font-family": "Monaco, monospace"
}

context.drawText(x,y,string); context.getFontAscent();
context.getFontDescent();
context.getFontLeading();
context.getTextWidth(string);

Best regards,
Stefan





David Hyatt wrote:

I think a drawText method would be extremely useful.

Rather than specifying stylistic information explicitly (via a  
font object), I'd use a special parenthetical pseudo-element. thus  
allowing the author to specify the style as for any other element  
on a page something like this...


canvas::canvas-text(barchart)
{
font-size: 8px;
font-family: Monaco, monospace;
}

and then the API would be something like:

drawText(y-coord of baseline, "barchart", myText)

and letter-spacing/word-spacing would work, small-caps would work,  
text-shadow would work, etc. etc.


fitTextToPath might be an interesting API too.

dave
([EMAIL PROTECTED])

On Oct 23, 2006, at 4:07 PM, Stefan Haustein wrote:


Gervase Markham wrote:

Stefan Haustein wrote:

I think drawElement(elem) opens up a whole new can of worms:

- how would an application determine the size of the text box?
- where is the baseline position, needed for exact axis label  
positioning?
- there are probably issues with dynamically calculated text  
values
- code with lots of cross references to elements will be  
difficult to read
- it needs to be specified whether css properties are inherited  
from the parent element of "elem".
- how much horizontal/vertical space is drawElement permitted  
to use for rendering?
The answer to all of these things is that the browser renders  
all the elements in the page as it would if the  were  
not supported and the alternate content were being used. It then  
basically screenshots the area corresponding to the element  
(yes, I know this needs careful definition) and draws that into  
the canvas.
I do not see how your statement answers any of my questions  
except from the last one. You can specify some CSS constraints,  
but how do you determine the actual rendering height of a text  
box with a specific width? How do you determine the pixel  
position of the baseline? The cross reference and the dynamic  
text issues are not addressed at all.
Like I said, we want to leverage the browser's deep and complex  
knowledge of text rendering as much as possible, and just take  
the resulting pixel output as it would be shown to the user.
- the implementation in actual browsers may be more complex  
than it seems because of problems with internal data structures  
for rendering hints and implicitly introducing the ability to  
render the same element twice.
- what happens with contained plugins, canvas elements, self- 
references... all this stuff needs to be well-defined
Indeed. I know it's easy to state and there are edge cases. But  
we could put limits on it like e.g. no plugins, no , and  
still have something very useful for rendering text.
So I assume we agree that the element rendering proposal would  
still need significant specification work and is probably much  
more difficult to implement. The element rendering approach may  
make working with bulk text simpler, but this case is already  
handled quite fine by HTML outside the Canvas element. By asking  
for too much, we may end up with nothing at all.


Andrew has provided a clear and simple proposal that can easily  
be implemented without too much consideration of side effects.  
Putting labels on maps, precise text positioning, starwars-like  
3d scrolling text, labels for game characters or in physics  
simulations, all the stuff that could only be done in a canvas  
element, is trivial to implement with the drawText() approach,  
but seems much more complex or impossible with the element  
rendering approach.
Moreover, drawElement() would not solve the drawText problem  
for non-browser environments such as Rhino.
How are we anticipating  might be used in a non-browser  
context?
Canvas and some other parts of the spec (e.g. connections) may  
make a lot of sense for Javascript outside of the browser  
context.  This may be outside of the scope of WHATWG, but if we  
can take out some building bl

Re: [whatwg] Canvas lack of drawString method

[David Hyatt]

I think a drawText method would be extremely useful.

Rather than specifying stylistic information explicitly (via a font  
object), I'd use a special parenthetical pseudo-element. thus  
allowing the author to specify the style as for any other element on  
a page something like this...


canvas::canvas-text(barchart)
{
font-size: 8px;
font-family: Monaco, monospace;
}

and then the API would be something like:

drawText(y-coord of baseline, "barchart", myText)

and letter-spacing/word-spacing would work, small-caps would work,  
text-shadow would work, etc. etc.


fitTextToPath might be an interesting API too.

dave
([EMAIL PROTECTED])

On Oct 23, 2006, at 4:07 PM, Stefan Haustein wrote:


Gervase Markham wrote:

Stefan Haustein wrote:

I think drawElement(elem) opens up a whole new can of worms:

- how would an application determine the size of the text box?
- where is the baseline position, needed for exact axis label  
positioning?

- there are probably issues with dynamically calculated text values
- code with lots of cross references to elements will be  
difficult to read
- it needs to be specified whether css properties are inherited  
from the parent element of "elem".
- how much horizontal/vertical space is drawElement permitted to  
use for rendering?
The answer to all of these things is that the browser renders all  
the elements in the page as it would if the  were not  
supported and the alternate content were being used. It then  
basically screenshots the area corresponding to the element (yes,  
I know this needs careful definition) and draws that into the canvas.
I do not see how your statement answers any of my questions except  
from the last one. You can specify some CSS constraints, but how do  
you determine the actual rendering height of a text box with a  
specific width? How do you determine the pixel position of the  
baseline? The cross reference and the dynamic text issues are not  
addressed at all.
Like I said, we want to leverage the browser's deep and complex  
knowledge of text rendering as much as possible, and just take the  
resulting pixel output as it would be shown to the user.
- the implementation in actual browsers may be more complex than  
it seems because of problems with internal data structures for  
rendering hints and implicitly introducing the ability to render  
the same element twice.
- what happens with contained plugins, canvas elements, self- 
references... all this stuff needs to be well-defined
Indeed. I know it's easy to state and there are edge cases. But we  
could put limits on it like e.g. no plugins, no , and  
still have something very useful for rendering text.
So I assume we agree that the element rendering proposal would  
still need significant specification work and is probably much more  
difficult to implement. The element rendering approach may make  
working with bulk text simpler, but this case is already handled  
quite fine by HTML outside the Canvas element. By asking for too  
much, we may end up with nothing at all.


Andrew has provided a clear and simple proposal that can easily be  
implemented without too much consideration of side effects. Putting  
labels on maps, precise text positioning, starwars-like 3d  
scrolling text, labels for game characters or in physics  
simulations, all the stuff that could only be done in a canvas  
element, is trivial to implement with the drawText() approach, but  
seems much more complex or impossible with the element rendering  
approach.
Moreover, drawElement() would not solve the drawText problem for  
non-browser environments such as Rhino.
How are we anticipating  might be used in a non-browser  
context?
Canvas and some other parts of the spec (e.g. connections) may make  
a lot of sense for Javascript outside of the browser context.  This  
may be outside of the scope of WHATWG, but if we can take out some  
building blocks and use them somewhere else, this is at least a  
sign of good and modular API design.


Best regards,
Stefan

Re: [whatwg] Canvas draw quality

[David Hyatt]

Except with something like canvas, people are going to care about the precise pixel-level details of the rendering.  We can't handwave these details away using vague terminology like low-quality or high-quality, where the user agent is free to decide what those terms mean.  If we do that, then we risk not having interoperability between browsers.daveOn Oct 20, 2006, at 10:44 PM, Andrew Fedoniouk wrote:Dave, various implementations use different libraries/approaches for the Graphics.Way of tuning parameters and their set can be different. I think that it is simply not possibleto generalize them all. At least something generic like preference=quality/speed switch makes real sense. Technically it is better to allow to get two Graphics instances for the same canvas and usethem at the same time if really needed. In any case 2D and 3D graphics shall coexist on the same surface. So why not 2D and 2D-fast ? In any case it is up to UA to provide multiple implementation for different values of contextID.contextID as a string is there in purpose I belive. That is the one. Andrew Fedoniouk.http://terrainformatica.com - Original Message -From: David HyattTo: Andrew FedonioukCc: Benjamin Joffe ; [EMAIL PROTECTED]Sent: Friday, October 20, 2006 10:12 PMSubject: Re: [whatwg] Canvas draw qualityI don't think a totally different context is a good idea.  Sometimes you want to mix antialiased and non-antialiased modes.The API in CG is part of the graphics state...CGContextSetShouldAntialiasI don't think an API like this should be vague about what it's doing... e.g., just using vague terms like "quality."  We should say what we mean... antialiasing for example.daveOn Oct 20, 2006, at 10:01 PM, Andrew Fedoniouk wrote: - Original Message -From: Benjamin JoffeTo: [EMAIL PROTECTED]Sent: Friday, October 20, 2006 9:09 PMSubject: [whatwg] Canvas draw qualityI would like to see a property added to the 2d canvas context that would allow quality to be lowered for drawing functions. Normally any time a shape is drawn, pixels close to the boundary are made semi transparent to make it look smooth, this is usually favourable but I have had a need to draw shapes and lines with pixel sharp boundaries in the same way as Java normally does. I would imagine that with the setting enabled, only the integer part of linewidth would be used. This setting would also affect drawing images, making them have no blurring or approximating when scaled or rotated. This could easily be implemented without affecting old scripts, making a property such as lowQuality = true; (default false). Or perhaps allowing more control: a float from 0 (low quality) to 1 (high quality), and interperating null as 1 for backwards compatibility. This property could also be handy in instaces where both fill() and stroke() are being called. Low quality could be used on the fill() to improve performace while stroke() could be used with high quality so it still draws smoothly. I think that the best way is just to define different values for the context ID:DOMObject getContext(in DOMString contextID);Something like "2D" and "2D-fast" or "2D-simple".Another option would be to add one optional parameter to the getContext() function. I doubt that someone will need to switch it in the middle of drawing sohaving such switch as an attribute is redundant. Andrew Fedoniouk.http://terrainformatica.com  

Re: [whatwg] Canvas draw quality

[David Hyatt]

I don't think a totally different context is a good idea.  Sometimes you want to mix antialiased and non-antialiased modes.The API in CG is part of the graphics state...CGContextSetShouldAntialiasI don't think an API like this should be vague about what it's doing... e.g., just using vague terms like "quality."  We should say what we mean... antialiasing for example.daveOn Oct 20, 2006, at 10:01 PM, Andrew Fedoniouk wrote: - Original Message -From: Benjamin JoffeTo: [EMAIL PROTECTED]Sent: Friday, October 20, 2006 9:09 PMSubject: [whatwg] Canvas draw qualityI would like to see a property added to the 2d canvas context that would allow quality to be lowered for drawing functions. Normally any time a shape is drawn, pixels close to the boundary are made semi transparent to make it look smooth, this is usually favourable but I have had a need to draw shapes and lines with pixel sharp boundaries in the same way as Java normally does. I would imagine that with the setting enabled, only the integer part of linewidth would be used. This setting would also affect drawing images, making them have no blurring or approximating when scaled or rotated. This could easily be implemented without affecting old scripts, making a property such as lowQuality = true; (default false). Or perhaps allowing more control: a float from 0 (low quality) to 1 (high quality), and interperating null as 1 for backwards compatibility. This property could also be handy in instaces where both fill() and stroke() are being called. Low quality could be used on the fill() to improve performace while stroke() could be used with high quality so it still draws smoothly. I think that the best way is just to define different values for the context ID:DOMObject getContext(in DOMString contextID);Something like "2D" and "2D-fast" or "2D-simple".Another option would be to add one optional parameter to the getContext() function. I doubt that someone will need to switch it in the middle of drawing sohaving such switch as an attribute is redundant. Andrew Fedoniouk.http://terrainformatica.com  

Re: [whatwg] Dynamic content accessibility in HTML today

[David Hyatt]

The XBL code in the Safari tree is dead.   It's not compiled, and it  
was based on XBL1 (Mozilla's XBL) anyway.


dave

On Aug 12, 2006, at 7:56 PM, Matthew Raymond wrote:


James Graham wrote:

Matthew Raymond wrote:
   What Firefox is doing for DHTML accessibility has a very  
narrow use
case. It applies to DHTML widgets, that are not bound to fallback  
markup

using XBL [...]


Without commenting (yet!) on the rest of this thread, I should  
just note
that any argument that relies on the near-future widespread  
deployment
of XBL is unconvincing. I would be extremely surprised if the  
entire XBL

spec is easier to implement than some targeted extensions to HTML,
therefore we shouldn't use it as a justification any more than any  
other

unlikely to be implemented soon technology.


   Mozilla is committed to having XBL 2.0 implemented as early as
version 3.0 of Firefox. Apple's WebCore has source code  
specifically for

XBL, so it isn't unreasonable to think that XBL will eventually be
implemented for Safari and KHTML. Ian Hickson was an employee of Opera
during most of the development of the XBL 2.0 draft, and the joint
Mozilla-Opera position paper sent to the W3C talks about XBL, so  
there's
some reason to believe that they'll eventually support XBL as well.  
So,

chances are that only Microsoft won't have XBL 2.0 implemented within
the next couple of years.

   Still, you're right about ease of implementation. The |role|
attribute is easier to implement, but that |class| is even easier
because it's already there.


[...] where a proper CSS presentation for the users primary media is
not available [...]


This is almost always the case on the real web.


   Yeah, the web masters are so lazy that they can't be bothered to  
add
accessibility via CSS, but they'll be working overtime putting in | 
role|

attributes using the correct predefined values.

/me rolls eyes.

   I don't see a significant difference between |role| and  
predefined

values for |class|.


Oh and I'm allergic to predefined class values :)


   I would suggest a strong antihistamine whenever you use a  
microformat.

Re: [whatwg] Canvas 2d methods

[David Hyatt]

I don't think it's intuitive to support chaining only on those  
methods that happen to return null right now.


dave
([EMAIL PROTECTED])

On Jul 2, 2006, at 4:01 PM, Ian Hickson wrote:


On Mon, 3 Jul 2006, Håkon Wium Lie wrote:


Anyway, this is all a straw man -- this isn't the reason that the  
spec
doesn't allow this. It doesn't allow this because Safari didn't  
do it

this way in the first place, and changing it would likely introduce
bugs (while still not helping authors for some time anyway).


It's still early in the life of the canvas element, and we still have
the luxury of listening to good proposals. We can deal with the minor
problems that arise, and authors down the road will have a more
intuitive syntax. I like the proposal.


Well as I mentioned, I'm fine with the idea per se, if implementors  
are
willing to change their implementations and fix any resulting bugs,  
then

the spec will follow.

--
Ian Hickson   U+1047E) 
\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _ 
\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'-- 
(,_..'`-.;.'

Re: [whatwg] Spellchecking proposal #2

[David Hyatt]

Strongly agree. :)

dave

On Jun 23, 2006, at 10:09 PM, Lachlan Hunt wrote:


Alexey Feldgendler wrote:
On Fri, 23 Jun 2006 10:22:34 +0700, Lachlan Hunt  
<[EMAIL PROTECTED]> wrote:
Roughly what percentage of all use cases would you expect  
heuristics and user preferences to give suboptimal results, and  
thus require the author's suggestion?
IMHO we should not rely on unspecified heuristics. In some  
browsers, they work rather well, in some they might constantly  
fail. Leave heuristics for invalid pages, quirks mode etc -- or  
document these heuristics.


Generally, that's true.  But since spell checking is only a user  
agent feature intended for the user (it doesn't affect the page or  
author in any way) and interoperability between one browser's  
heuristics and another is not required.  Browsers should be allowed  
to innovate as much as they like so they can come up with the best  
method that suits their users.


--
Lachlan Hunt
http://lachy.id.au/

Re: [whatwg] Spellchecking proposal #2

[David Hyatt]

The only time spell checking matters is when the user is the one  
creating the content (not the author).  It doesn't make any sense to  
spell check non-editable content that the user didn't even create.   
If the content is editable, then spell checking should just be left  
up to the preference of the user who is editing the content.  I  
really don't see the point of this feature being included in markup.   
If Mozilla wants it, fine, but I don't think it should be in HTML5.


dave
([EMAIL PROTECTED])

On Jun 22, 2006, at 5:42 PM, Ian Hickson wrote:

I'd be happy without the attribute at all, but Mozilla is going to  
have
something to enable/disable this feature from markup, and they  
wanted to
have a spec for it so they asked WHATWG to provide a strawman. I  
figure

it's better to have a spec and an implementation than just an
implementation...

--
Ian Hickson   U+1047E) 
\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _ 
\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'-- 
(,_..'`-.;.'

Re: [whatwg] Spellchecking proposal #2

[David Hyatt]

If the user wants spell checking on in all textareas, then it should  
be on, regardless of what the page says.  I don't think the page  
should be allowed to override spell checking rules, since this is  
really a user decision.  For example, I know how to spell, so I don't  
want spell checking on in any controls.  A person with poor spelling,  
however, might want spell checking on in all controls.  I think it's  
totally inappropriate for a Web page to have any control over spell  
checking settings.


dave
([EMAIL PROTECTED])

On Jun 22, 2006, at 9:04 AM, Ian Hickson wrote:



Based on the fedback recently received about how to do  
spellchecking in

HTML, here's a second proposal that uses an attribute to control it.
Comments? (Don't worry about typos and other such minor mistakes.)


AUTHOR REQUIREMENTS

 and  elements may have a new attribute specified,
"spellcheck".  If specified, it must have either the value "on" or the
value "off" (exactly, case-sensitive). The "on" value indicates that
spellchecking is to be enabled, the "off" value indicates that
spellchecking is to be disabled. If the attribute is omitted, the
default value is to use the user preferences.

In addition, there is a "spellcheck" DOM attribute on all elements. On
HTMLInputElement and HTMLTextareaElement elements, it returns true if
the content attribute is "on", false if the attribute is "off", and
the user's preference if the attribute is not set. On other elements,
it also returns the current state of spellchecking for that element,
but this is not represented in a content attribute. The attribute may
be set to "true" to enable spellchecking, or "false" to disable it. On
elements other than HTMLInputElement and HTMLTextareaElement, this is
only expected to be useful if contenteditable="" is used.

Authors should set the document's language information, to enable user
agents to accurately determine which dictionary to use when checking
the spelling or grammar of user input.


IMPLEMENTATION REQUIREMENTS

All elements can have spellchecking enabled or disabled. UAs may allow
the user to set this flag, and may have defaults that vary based and
various heuristics or user preferences. Spellchecking can be enabled
on an element while its children have it disabled. However, by
default, user agents should enable spellchecking for an element if it
is enabled for its parent element and not explicitly disabled for the
child.

If spellchecking is enabled on an element, the UA should indicate
spelling and/or grammar errors in text nodes that are direct
descendants of the element that the user is able to edit, in
attributes of the element that the user is able to edit, and, for
elements that are form controls that accept arbitrary text input, in
the values of those elements.

If spellchecking is disabled, the UA should not indicate spelling or
grammar errors for that element's text and values.

UAs should use the language of the element to determine what spelling
and grammar rules to use. (Language information can come from the
"lang" and "xml:lang" attributes, Content-Language HTTP headers, or
other sources. q.v.)

The HTMLElement interface has one new DOM attribute:

  attribute boolean spellcheck;

Every element remembers what its "spellcheck" DOM attribute was last
set to, if it has ever been set.

On getting, the "spellcheck" DOM attribute returns a value as
determined by the following algorithm.

 * If the element is an "input" element or a "textarea" element, and
   the element has a "spellcheck" content attribute with the exact
   literal value "on", then the DOM attribute must return true.

 * Otherwise, if the element is an "input" element or a "textarea"
   element, and the element has a "spellcheck" content attribute with
   the exact literal value "off", then the DOM attribute must return
   false.

 * Otherwise, if the element is an "input" element or a "textarea"
   element, then the DOM attribute must return true if spellchecking
   is enabled on the element, and false otherwise.

 * Otherwise, the element is neither an "input" element nor a
   "textarea" element. If the DOM attribute has been set, then it must
   return the value it was last set to.

 * Otherwise, the element is neither an "input" element nor a
   "textarea" element, and the DOM attribute has never been set. The
   DOM attribute must return true if spellchecking is enabled on the
   element, and false otherwise.

Setting the DOM attribute has the effect determined by the following
algorithm:

 * If the element is an "input" element or a "textarea" element, then
   the element's "spellcheck" content attribute must be set to the
   literal value "on" if the attribute is being set to the "true"
   value, and "off" otherwise. (This affects the spellchecking of the
   element, see below.)

 * Otherwise, the element's spellchecking should be enabled if the DOM
   attribute is set to the value true, and should be disabled
   otherwise.

On "input" and "textarea" e

Re: [whatwg] proposed canvas 2d API additions

[David Hyatt]

This mail showed up pointlessly out of order. I see Ian already  
responded. :)


dave

On Apr 22, 2006, at 6:15 PM, David Hyatt wrote:

The getPixels proposal seems broken to me in that it does not take  
into account high DPI, i.e., a situation where the canvas pixel  
space has been scaled and a more detailed image is possibly  
rendering within a region of the canvas.  In this situation, a  
"canvas pixel" could actually be a bunch of device pixels that  
contain different color information.


dave
([EMAIL PROTECTED])

On Apr 21, 2006, at 12:10 PM, Vladimir Vukicevic wrote:


Hi folks,

I'd like to suggest extending the HTML canvas 2d context with a few
additions.  These are variations on some of the methods added to
Opera's "opera-2dgame" context.  The methods are intended to give
content authors direct pixel access to the canvas, as well as provide
some basic point-in-path testing functionality.

float [] getPixels (in integer x, in integer y, in integer width,
in integer height);

Returns an array of floats representing the color values in the  
region

of pixels in the canvas whose upper left corner is at (x,y) and which
extends for width,height pixels.  These coordinates are in canvas
pixel space (that is, the same space that the canvas width and height
attributes are specified in).  The color values for each pixel are
returned as 4 floats, each in the range of 0.0 to 1.0, in R,G,B,A
order.  That is, given the paramters (0,0,2,2), the returned array
will be [R00 G00 B00 A00 R10 G10 B10 A10 R01 G01 B01 A01 R11 B11 G11
A11].

Note: we could return the pixels as integers in the range of 0..255,
as 8-bit color is most likely what canvases will be dealing with.
However, using floats allow us to easily extend into a 16-bit
colorspace without any API changes.  In addition, any computation
using these pixels is often done in normalized colors, so the  
division

by 255 would need to happen anyway.

void putPixels (in float [] pixels, in integer x, in integer  
y, in

integer width, in integer height);

Does the opposite of getPixels; the given array must be exactly width
* height * 4 elements in length.  The values are to be clamped to
0.0..1.0.

boolean pointInPathFill(in float x, in float y);

pointInPathFill returns true if the given point would be inside the
region filled by the current path, and false otherwise.  The x,y
coordinates are in the current space of the canvas; that is, they are
transformed by the CTM and do not necessarily map directly to pixels.

I'd suggest that these three functions be added directly to the "2d"
context; content authors can test for their presence by checking the
function is not null on the 2d context object.  We might want a more
comprehensive way of letting authors test whether particular features
are supported, e.g. "shadows", "pixel-access", etc, but maybe it's  
not

necessary.

How's this sound?

- Vlad

Re: [whatwg] proposed canvas 2d API additions

[David Hyatt]

The getPixels proposal seems broken to me in that it does not take  
into account high DPI, i.e., a situation where the canvas pixel space  
has been scaled and a more detailed image is possibly rendering  
within a region of the canvas.  In this situation, a "canvas pixel"  
could actually be a bunch of device pixels that contain different  
color information.


dave
([EMAIL PROTECTED])

On Apr 21, 2006, at 12:10 PM, Vladimir Vukicevic wrote:


Hi folks,

I'd like to suggest extending the HTML canvas 2d context with a few
additions.  These are variations on some of the methods added to
Opera's "opera-2dgame" context.  The methods are intended to give
content authors direct pixel access to the canvas, as well as provide
some basic point-in-path testing functionality.

float [] getPixels (in integer x, in integer y, in integer width,
in integer height);

Returns an array of floats representing the color values in the region
of pixels in the canvas whose upper left corner is at (x,y) and which
extends for width,height pixels.  These coordinates are in canvas
pixel space (that is, the same space that the canvas width and height
attributes are specified in).  The color values for each pixel are
returned as 4 floats, each in the range of 0.0 to 1.0, in R,G,B,A
order.  That is, given the paramters (0,0,2,2), the returned array
will be [R00 G00 B00 A00 R10 G10 B10 A10 R01 G01 B01 A01 R11 B11 G11
A11].

Note: we could return the pixels as integers in the range of 0..255,
as 8-bit color is most likely what canvases will be dealing with.
However, using floats allow us to easily extend into a 16-bit
colorspace without any API changes.  In addition, any computation
using these pixels is often done in normalized colors, so the division
by 255 would need to happen anyway.

void putPixels (in float [] pixels, in integer x, in integer y, in
integer width, in integer height);

Does the opposite of getPixels; the given array must be exactly width
* height * 4 elements in length.  The values are to be clamped to
0.0..1.0.

boolean pointInPathFill(in float x, in float y);

pointInPathFill returns true if the given point would be inside the
region filled by the current path, and false otherwise.  The x,y
coordinates are in the current space of the canvas; that is, they are
transformed by the CTM and do not necessarily map directly to pixels.

I'd suggest that these three functions be added directly to the "2d"
context; content authors can test for their presence by checking the
function is not null on the 2d context object.  We might want a more
comprehensive way of letting authors test whether particular features
are supported, e.g. "shadows", "pixel-access", etc, but maybe it's not
necessary.

How's this sound?

- Vlad

Re: [whatwg] Empty elements

[David Hyatt]

BTW, not sure if you have this in the WhatWG parsing spec, but a  
stray  (that does not match some opening ) has to be treated  
like an open .


Also,  is actually supported even in HTML by  
Firefox and Safari.  We're stuck with it forever as well, since most  
of the Dashboard widgets use  in HTML.  It isn't  
understood by WinIE or Opera though.  You can say we're wrong in the  
spec, but we won't be able to change it. :(


dave
([EMAIL PROTECTED])

On Feb 15, 2006, at 4:16 PM, Ian Hickson wrote:


On Wed, 15 Feb 2006, Michael Enright wrote:


What about '' with a space between 'o' and '/' ? There are  
many
"legacy" pages with that kind of mark-up on  elements and so  
forth.


There are also lot of legacy pages that do it on things like ,  
sadly.


On  it's harmless, and it doesn't help either way to say that it
makes an empty element, since it's empty anyway. On other elements, it
makes HTML5 UAs have a different DOM that legacy UAs.

--
Ian Hickson   U+1047E) 
\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _ 
\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'-- 
(,_..'`-.;.'

Re: [whatwg] Update to the Adoption Agency Algorithm

[David Hyatt]

BTW, we tried to add  as an inline that should be reopened  
(like  and  etc.) and it broke some of our layout tests  
(snippets of real-world Web sites).   clearly does not always  
reopen in WinIE and Firefox, so for now we are having to leave it out.


dave

On Feb 2, 2006, at 11:01 AM, Blanchard, Todd wrote:

What I want to know is:  if the "cloned" node has an id attribute,  
and id is meant to be unique, then how do we resolve this  
conflict?  I mention this because bad html and duplicate id's in  
documents have caused havoc when trying to build javascript  
applications.


-Todd Blalnchard

-Original Message-
From: [EMAIL PROTECTED] [mailto:whatwg- 
[EMAIL PROTECTED] On Behalf Of Ian Hickson

Sent: Friday, January 27, 2006 6:12 PM
To: [EMAIL PROTECTED]
Subject: [whatwg] Update to the Adoption Agency Algorithm


Just a note to those of you who reviewed the new parsing rules  
yesterday:

I changed them today to take into account some feedback from Hyatt.
Basically the old algorithm was creating too many nodes. This is  
now fixed, the algorithm only moves the nodes that are being  
closed, not the other inlines it happens to cross.


   http://whatwg.org/specs/web-apps/current-work/#closing

Cheers,
--
Ian Hickson   U+1047E) 
\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _ 
\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'-- 
(,_..'`-.;.'

Re: [whatwg] Tag Soup: Blocks-in-inlines

[David Hyatt]

Anything the WHATWG specifies in this area must be largely compatible  
with WinIE.  If you specify error recovery that would yield  
dramatically different results, then nobody is going to implement  
it.  Safari's algorithm is designed to keep a relatively sane DOM, to  
keep the performance snappy by not needlessly creating extra  
elements, and most importantly to be compatible in as many cases as  
possible with WinIE.


People keep throwing out algorithms in this thread that would yield  
dramatically different renderings from what browsers do now (and what  
WinIE does in particular), and that's just impractical and naive.   
This is not an area of the Web where you get to just wave a magic  
wand and re-invent the last 10 years of browser HTML parsing.  You  
are constrained forever by what browsers do now.


dave
([EMAIL PROTECTED])

Re: [whatwg] Tag Soup: Blocks-in-inlines

[David Hyatt]

We used to not reopen the tags.  It was the #1 rendering bug in our  
engine.  We had over 60 unique duplicates of the bug in our internal  
database.  All that would happen if we didn't reopen the tags is that  
people would switch to another browser. :)


dave

On Jan 25, 2006, at 11:31 PM, Blanchard, Todd wrote:

I have to ask - why reopen the tags?  Why not throw them on the  
floor?  They're wrong anyhow and cause problems.  If bad code  
didn't (sort of) work, people would write different code.  That  
would be good.


IOW:
stuff looks like

Body
  +em
  +p
+stuff



[EMAIL PROTECTED] wrote:

For example, allowing blocks inside inlines minimizes the number of  
residual style tags that you have to re-open, and deferring the  
reopening of such tags until a misnested close tag is encountered  
ensures that well- formed documents don't end up with a bloated  
DOM.  ...
Your DOM would grow unacceptably large on real-world pages if you  
try to restrict blocks from being inside inlines and end up  
reopening the inlines over and over again inside each block.


On Jan 25, 2006, at 5:41 PM, Ian Hickson wrote:


On Wed, 25 Jan 2006, Simon Pieters wrote:


Thus, XY should be parsed as:

BODY
  + EM
  + P
+ EM
  + #text: XY

Re: [whatwg] Tag Soup: Blocks-in-inlines

[David Hyatt]

My 2 cents.

It took me a long time to develop an algorithm that actually fixed  
all 60 of the duplicate internal Apple bugs on this subject.  I'm  
reluctant to revisit this problem in our code base, given that my  
current algorithm was developed both to solve the problem and to be  
extremely performant and internally consistent.  For example,  
allowing blocks inside inlines minimizes the number of residual style  
tags that you have to re-open, and deferring the reopening of such  
tags until a misnested close tag is encountered ensures that well- 
formed documents don't end up with a bloated DOM.  Blocks inside  
inlines simply must be allowed.


Your DOM would grow unacceptably large on real-world pages if you try  
to restrict blocks from being inside inlines and end up reopening the  
inlines over and over again inside each block.  Not to mention that  
even without the residual style problem, sites rely on being able to  
nest blocks inside inlines (for example, an inline link that wraps  
multiple paragraphs but expects them to be a single link and not  
multiple links).


dave
([EMAIL PROTECTED])

On Jan 25, 2006, at 5:41 PM, Ian Hickson wrote:


On Wed, 25 Jan 2006, Simon Pieters wrote:


Thus, XY should be parsed as:

BODY
  + EM
  + P
+ EM
  + #text: XY

...IMHO.


This breaks in the face of , sadly (see my earlier  
mail).

Otherwise I'd agree.

--
Ian Hickson   U+1047E) 
\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _ 
\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'-- 
(,_..'`-.;.'

Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted

[David Hyatt]

As a child of a  or .

dave

On Dec 7, 2005, at 8:47 PM, Matthew Raymond wrote:


David Hyatt wrote:

Shipping Safari actually supports  as separators in 
dropdowns now.  We needed this for Dashboard widgets that wanted to
be able to put separators into their select UI.


   Is that inside an  or as a direct child of ?

Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted

[David Hyatt]

Shipping Safari actually supports  as separators in   
dropdowns now.  We needed this for Dashboard widgets that wanted to  
be able to put separators into their select UI.


dave

On Dec 7, 2005, at 4:00 PM, Ian Hickson wrote:




Then again, toolbars often have separators, so maybe they're a  
type of
list anyways and require -type markup, thus making   
more

appropriate. Hmm...


 is our separator element. Not sure what it stands for exactly.  
"Here

is a separatoR", maybe. *cough*


Above, the type "menu" is assumed to be a sort of context menu  
activated
either by a true context menu feature or by a . Then  
again,

-type elements are flat, and while they may have
groupings/separators (for toolbars, at least), they don't have
multilevel groupings.


They kind of do, in some contexts, e.g. drop-down buttons.

--
Ian Hickson   U+1047E) 
\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _ 
\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'-- 
(,_..'`-.;.'

Re: [whatwg] rel/rev for ?

[David Hyatt]

The class attribute! So efficient it must be wrong! :)

dave
([EMAIL PROTECTED])

On Nov 8, 2005, at 12:30 AM, Anne van Kesteren wrote:


Quoting Mike Dierken <[EMAIL PROTECTED]>:

[1] http://www.whatwg.org/specs/web-apps/current-work/#profile
Can the 'class' attribute have multiple values? If not, then a new  
attribute
would be needed, unless we overload the use of 'class' for  
presentation with

the use of 'class' for semantic purposes.


The use of 'class' for presentation is wrong anyway (and hopefully  
obsoleted in
HTML 5). And yes, although it is named incorrectly, the attribute  
can take

multiple, space-separated, values.


--
Anne van Kesteren