Re: [whatwg]

[Benjamin Hawkes-Lewis]

Sander Tekelenburg wrote:


And while we add all that presentational HTML to the spec, some enterprising
hacker builds a HTML->PDF converter that has CSS support -- we'll have a spec
allowing things we didn't really want to allow and for which there's not even
a use case anymore.


Well, PrinceXML does just that:

http://www.princexml.com/

http://alistapart.com/articles/boom/

Unfortunately, there's no free alternative AFAIK.

--
Benjamin Hawkes-Lewis

[whatwg] Editorial: value attribute of the li element

[Thomas Broyer]

In  :
   The value  attribute, if present, must be a valid integer giving the
   ordinal value of the first list item.

Shouldn't it be "the ordinal value of the list item" instead of "the
first list item"?

Looks like a copy/paste from the from attribute of the ol element:
   The start  attribute, if present, must be a valid integer giving the
   ordinal value of the first list item.
   — http://www.whatwg.org/specs/web-apps/current-work/#start0

--
Thomas Broyer

Re: [whatwg]

[Sander Tekelenburg]

At 06:48 +1000 UTC, on 2007-05-03, Adrian Sutton wrote:

> On 3/5/07 2:23 AM, "Sander Tekelenburg" <[EMAIL PROTECTED]> wrote:

[HTML -> PDF converters ignore CSS]

>> OK. Real world issues. But that doesn't mean that the HTML spec is the place
>> to fix those. Looks more like an opportunity for beter PDF generators to
>>grab
>> market share and for IE to fix security bugs.
>
> Well sure you can ignore the real world if you like, I'm just letting you
> know what's currently happening.

Which I very much appreciate. I didn't mean to suggest otherwise.

> If the spec chooses to ignore that then
> it's gambling on the fact that implementors care more about being spec
> compliant than making things work for their clients.

I don't think we need look at it in such a dramatic way. While some people
may 'need'  because their HTML -> PDF converter ignores CSS, I imagine
they'd much rather have a HTML -> PDF converter that *does* support CSS. That
would give them much more control over their final product after all.

Now if there is something about the HTML spec that stands in the way of
HTML->PDF converters to support CSS, that would logically be something to try
to fix in the HTML spec. But otherwise I don't see why HTML should try to
solve it, or even how it *could*. Authors can generate  already anyway.
Their document just won't be conforming. What would those authors win by
 being conforming? And then what about the rest of their problems?
Because if their problem is their tool ignores CSS, they'll likely need much
more presentational HTML than just .

And while we add all that presentational HTML to the spec, some enterprising
hacker builds a HTML->PDF converter that has CSS support -- we'll have a spec
allowing things we didn't really want to allow and for which there's not even
a use case anymore.


-- 
Sander Tekelenburg
The Web Repair Initiative: 

Re: [whatwg]

[Adrian Sutton]

On 3/5/07 2:23 AM, "Sander Tekelenburg" <[EMAIL PROTECTED]> wrote:
> OK. Real world issues. But that doesn't mean that the HTML spec is the place
> to fix those. Looks more like an opportunity for beter PDF generators to grab
> market share and for IE to fix security bugs.

Well sure you can ignore the real world if you like, I'm just letting you
know what's currently happening. If the spec chooses to ignore that then
it's gambling on the fact that implementors care more about being spec
compliant than making things work for their clients. That's not to
discourage the spec from going after the most ideal solution, but if we want
the spec to be useful we do need to consider the impact these decisions have
in the real world.

> Right. Given that that is what they're used to that's understandable. However
> "used to" implies that the same people could work with a more semantic
> editor, if they'd be used to that. People get born every day without yet
> being used to Word.

I wish you the best of luck with that project (no sarcasm intended). To date
I have seen numerous people try and fail. In our editors we're trying to
find ways to make it easier for people to generate semantic content and
leave the presentation to the stylesheet, but we still haven't managed to
get rid of the allure of the font menu. We'll keep trying though.

It really is worth noting in this that the font tag currently allowed by the
spec is comletely and utterly useless and should be removed. It's only
useful if it allows the size and face attributes and even then I'm not sure
there's a reason to bring it back after it's already been removed from other
HTML standards.

Regards,

Adrian Sutton.
__
Adrian Sutton, Integrations Product Manager
Global Direct: +1 (650) 292 9659 x717  Australia: +61 (7) 3858 0118
UK +44 (20) 8123 0617 x717Mobile +61 (4) 222-36329
Ephox ,   Ephox Blogs 

Re: [whatwg] Cue points in media elements

[Kevin Calhoun]

On May 2, 2007, at 11:01 AM, Dave Singer wrote:


At 17:04  -0400 1/05/07, Brian Campbell wrote:

On May 1, 2007, at 1:05 PM, Kevin Calhoun wrote:

I believe that a cue point is "reached" if its time is traversed  
during playback.


What does "traversed" mean in terms of (a) seeking across the cue  
point (b) playing in reverse (rewinding) and (c) the media stalling  
an restarting at a later point in the stream?


I would say that playing (at any rate and in any direction) is a  
continuous function, and therefore cue points are triggered, when  
playing, whenever two samples of the time straddle the cue point  
(where straddel includes one of the samples being at the cue point).


Seeking is discontinuous, and therefore cue points are triggered  
only if a seek results in landing on the cue point, if not playing.   
If playing, then the usual rules apply.


A discontinuous jump will result in a timeupdate notification, which  
among other things is supposed to enable scripts to issue  
notifications of interesting times that are traversed not during  
playback but while seeking.

Re: [whatwg] Cue points in media elements

[Dave Singer]

At 17:04  -0400 1/05/07, Brian Campbell wrote:

On May 1, 2007, at 1:05 PM, Kevin Calhoun wrote:

I believe that a cue point is "reached" if its time is traversed 
during playback.


What does "traversed" mean in terms of (a) seeking across the cue 
point (b) playing in reverse (rewinding) and (c) the media stalling 
an restarting at a later point in the stream?


I would say that playing (at any rate and in any direction) is a 
continuous function, and therefore cue points are triggered, when 
playing, whenever two samples of the time straddle the cue point 
(where straddel includes one of the samples being at the cue point).


Seeking is discontinuous, and therefore cue points are triggered only 
if a seek results in landing on the cue point, if not playing.  If 
playing, then the usual rules apply.


Frame dropping, stalling, and so on, are aspects of the playback 
behavior and nothing to do with the logical model of cues laid on a 
time axis.

--
David Singer
Apple Computer/QuickTime

Re: [whatwg]

[Sander Tekelenburg]

At 11:01 +1000 UTC, on 2007-05-02, Adrian Sutton wrote:

> On 2/5/07 1:28 AM, "Sander Tekelenburg" <[EMAIL PROTECTED]> wrote:

[...]

>> can you explain exactly how span is much more difficult to work
>> with, and for whom?
>
> Quite a number of the cheap HTML to PDF conversion processes don't support
> CSS. Additionally, syndicated HTML (via Atom, RSS etc) tends to have inline
> CSS removed because of cross site scripting vulnerabilities (you can embed
> JavaScript in CSS and at least IE will execute it).

OK. Real world issues. But that doesn't mean that the HTML spec is the place
to fix those. Looks more like an opportunity for beter PDF generators to grab
market share and for IE to fix security bugs.

[...]

> Some people do restrict the editor to just applying
> predefined CSS classes and as a result they get a very consistent, easy to
> maintain site. Most however, prefer having the flexibility of a font menu so
> they can apply the specific font they won't precisely when they want it.

OK. Too bad. Still, I don't see why this would warrant making 
conforming.

> [...] People want the editor to look and
> work like Microsoft Word and Word has a font menu.

Right. Given that that is what they're used to that's understandable. However
"used to" implies that the same people could work with a more semantic
editor, if they'd be used to that. People get born every day without yet
being used to Word.


-- 
Sander Tekelenburg
The Web Repair Initiative: 

Re: [whatwg] additional empty elements

[Geoffrey Sneddon]

On 1 May 2007, at 20:21, Brenton Strine wrote:


However, if I then wanted to add additional special
styling to the first and third div, (e.g.. a border and
background color) it is less graceful. I could add style
attributes, but that would be wasteful if I want to do
this on a large scale. Multiple classes would be
confusing.

A nice solution would be the addition of a few div tags.
(e.g. , ,  and .) Then you could
do something like this:


div1 {text-indent:0px;}
div2 {text-indent:10px;}
div3 {text-indent:20px;}



Why not:



.first {
color: red;
}
.first + div {
text-indent: 10px;
}
.first + div + div {
text-indent: 20px;
color: blue;
}

Indent 0
Indent 1
Indent 2
Indent 0
Indent 1
Indent 2

Re: [whatwg] (was Support Existing Content)

[Adrian Sutton]

On 2/5/07 4:59 PM, "Benjamin Hawkes-Lewis" <[EMAIL PROTECTED]>
wrote:
> Adrian Sutton wrote:
> 
>> That said, by default our editor outputs the span tag version because we
>> like to follow standards and I recommend using our styles menu to apply CSS
>> classes and appropriate structural markup (headings etc). We did however
>> have to go back and add an option to output font tags because of user
>> complaints.
> 
> Why did these user complaints arise? How did the end-users tell the
> difference between the span and font elements?

They had backend systems that didn't support CSS. Like PDF conversion
utilities etc.

> Benjamin Hawkes-Lewis

Regards,

Adrian Sutton.
__
Adrian Sutton, Integrations Product Manager
Global Direct: +1 (650) 292 9659 x717  Australia: +61 (7) 3858 0118
UK +44 (20) 8123 0617 x717Mobile +61 (4) 222-36329
Ephox ,   Ephox Blogs