Re: [whatwg] DOM-related and API-related feedback

[Ian Hickson]

On Wed, 1 Apr 2009, Kevin Field wrote:
> On Sun Dec 28 03:38:07 PST 2008, Ian Hickson wrote:
> > On Sun, 8 Jun 2008, Ojan Vafai wrote:
> > > 
> > > I can speak to the first (getNextFocusableElement). One case I have 
> > > hit where this would be useful is a designMode iframe (in this case 
> > > a rich-text editor). I wanted tab to go to the next focusable 
> > > element, which was a different element depending on the context the 
> > > editor is embedded in. There's currently no way to do that.
> > 
> > It seems like this is something that should be left up to the user 
> > agent. After all, how is the Web page to know which key binding moves 
> > the focus normally anyway?
> > 
> > If we were to provide this it seems what we'd have to do is provide an 
> > API that actually moves the focus (e.g. provide a focusNextElement() 
> > method and a focusPreviousElemnt() method), since the next focusable 
> > item might not even have a DOM node (e.g. the location bar) or it 
> > might be in another origin. But then what if the user agent doesn't do 
> > things using a cycle but instead uses directional focus management, 
> > like many phones?
> 
> I'm currently working on a UI that I intend to be fully usable via 
> keyboard or mouse.  When an element is given focus, a mouse-usable UI is 
> generated, but the focused element also accepts keystrokes.  It appears 
> to be currently very difficult to have the element give its focus over 
> to the next available focusable element when the user clicks something 
> in the mouse-usable UI.  So I'm not replacing tab or whatever the 
> keybinding might be, but I do want a click in one area to be followed by 
> a simulated tab (or equivalent) keypress.  This is an important use case 
> for me.
> 
> I propose extending the blur() function to act like history.go(): 
> element.blur(-1) would act like element.focus() plus a shift + tab (or 
> equivalent) keypress, and element.blur(1) would act like element.focus() 
> plus a tab (or equivalent) keypress.
> 
> Your final question made me stop and think, but in the end, "6.5.1 
> Sequential focus navigation" and the tabindex attribute already exist.  
> This should still work.  Developers targeting phone platforms would 
> simply not make use of this function, and in any case, phone users would 
> still have their directional focus management available unless the 
> developer was malicious, in which case she or he could just abuse 
> element.focus() or other existant technologies as-is.

I once drafted something along these lines in the Web Controls draft:

   http://www.whatwg.org/specs/web-controls/current-work/#the-documentui

I haven't added this to HTML5 at this point (I'm concerned about feature 
creep, and I'd rather address this along with other editing problems all 
at once, probably in its own spec), but I think it's something we should 
definitely keep in mind.

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

Re: [whatwg] About Descendent Tags

[Ian Hickson]

On Fri, 1 May 2009, Christoph P�per wrote:
> Ian Hickson:
> > On Tue, 7 Apr 2009, Kristof Zelechovski wrote:
> > > 
> > > The header element is not for the page header, it is for grouping section
> > > headings, and the tag name chosen for this element is misleading.
> > 
> > I've renamed the old  to .
> 
> Did you consider using 'h' instead?

I think that would be confusing for people who have heard of XHTML2's  
(since it is quite different; HTML5's  is the better match there). 
Normally that wouldn't be a great concern, but this is one feature of 
XHTML2 that has received a lot of attention from early adopters, and so 
confusion on this front could set the wrong trajectory for a long time to 
come. That is, after all, why we renamed the elements in the first place. :-)

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

Re: [whatwg] About Descendent Tags

[Christoph Päper]

Ian Hickson:

On Tue, 7 Apr 2009, Kristof Zelechovski wrote:


The header element is not for the page header, it is for grouping  
section

headings, and the tag name chosen for this element is misleading.


I've renamed the old  to .


Did you consider using 'h' instead?

Re: [whatwg] / feedback

[David Singer]

At 11:42  +1000 1/05/09, Silvia Pfeiffer wrote:

re c):
It depends on how the UA displays it. If the UA displays the 5s offset
as the beginning of the video, then the user cannot easily jump to 0s
offset. I thought this was the whole purpose of the discussion:
whether we should encourage UAs to display just the addressed segment
in the timeline (which makes sense for a 5sec extract from a 2 hour
video) or whether we encourage UAs to display the timeline of the full
resource only.


I think we came to a slightly more abstract conclusion, that the UA 
focuses the user's initial attention on the indicated fragment.


[And we are silent about how it does that, and also about how easy it 
is to look elsewhere.]



I only tried to clarify the differences for the UA and
what the user gets, supporting an earlier suggestion that UAs may want
to have a means for switching between full timeline and segment
timeline display. Ultimately, it's a UA problem and not a HTML5
problem.


Exactly, agreed.
--
David Singer
Multimedia Standards, Apple Inc.

Re: [whatwg] converting word (was attributes

[Adrian Sutton]

On 01/05/2009 12:27, "Bruce Lawson"  wrote:
> On Fri, 01 May 2009 12:22:32 +0100, Adrian Sutton
>  wrote:
> Off topic, I know - but couldn't a VBA macro hook into word and actually
> make an "export as semantic html" option that exported the heading levels
> as h1..h6, honoured bold, italics, links, bullets and numbers as ul and
> ol, and just ignored all colours, font changes etc. So there is nothing to
> clean up?

Yes, but you'd have to get users to install the macro and get around virus
checkers etc. Then you'd have to write a separate applescript version for
Mac.  I'm not sure how difficult all that would be - it's cheaper for us to
just tweak and update the existing filtering code than it would be to go
down this route now.

It also wouldn't give the option to preserve the styles, but in a HTML
compliant way which the filtering process does give (and pretty impressive
accuracy in rendering given how little control HTML gives compared to Word's
native model). EditLive! for example could include the styles as either an
embedded stylesheet (thus preserving any custom styles from word as class
names) or inline styles (thus making a very messy but compliant bit of HTML
but useful if you're only editing a fragment).

For the record, OpenOffice and it's variants tend to create pretty good HTML
out of the box and don't need this kind of filtering at all.  Excel is even
surprisingly good but does add some proprietary attributes.

Regards,

Adrian Sutton.
__
Adrian Sutton, CTO
UK: +44 1 753 27 2229  US: +1 (650) 292 9659 x717
Ephox 
Ephox Blogs , Personal Blog

Re: [whatwg] converting word (was attributes

[Bruce Lawson]

On Fri, 01 May 2009 12:22:32 +0100, Adrian Sutton  
 wrote:



The biggest challenge in this is actually removing the huge amount of  
inline
formatting and proprietary tags/attributes that Microsoft Word adds.  In  
the
latest versions it's also a challenge to put lists back together as  
actual
HTML lists since Word has started exporting them as paragraphs with a  
bullet

from the symbol font and lots of nbsps.


Off topic, I know - but couldn't a VBA macro hook into word and actually  
make an "export as semantic html" option that exported the heading levels  
as h1..h6, honoured bold, italics, links, bullets and numbers as ul and  
ol, and just ignored all colours, font changes etc. So there is nothing to  
clean up?


bruce

Re: [whatwg] converting word (was attributes

[Adrian Sutton]

On 01/05/2009 12:03, "Charles McCathieNevile"  wrote:
> This is an oversimplification to the point of being misleading.
> 
> There are many ways to use Word, and many people and organisations with
> haf a clue use it in such a way that automatic conversion can be
> relatively easily used to generate highly semantically rich and valid
> markup - much better than the sort of tripe one typically finds on the Web
> today.

I can verify this with a lot of real world experience.  Ephox has been
selling a WYSIWYG editor for around 10 years now and the single most popular
feature is it's ability to copy and paste clean HTML from Microsoft Word.
The resulting HTML brings over the structure of the document (headings,
tables, lists, images etc) but not the inline formatting so the content then
matches the CSS.  The formatting and styles can optionally be brought over
as well but in the last 3-5 years popular demand has been to match the site
stylesheet rather than the original formatting.

The biggest challenge in this is actually removing the huge amount of inline
formatting and proprietary tags/attributes that Microsoft Word adds.  In the
latest versions it's also a challenge to put lists back together as actual
HTML lists since Word has started exporting them as paragraphs with a bullet
from the symbol font and lots of nbsps.

Pretty much every editor I know of can preserve the semantic information
from Word when copying and pasting, they all vary in how well they strip out
the inline formatting and proprietary tags with most doing a fairly poor job
of this second part.

Regards, 

Adrian Sutton.
__
Adrian Sutton, CTO
UK: +44 1 753 27 2229  US: +1 (650) 292 9659 x717
Ephox 
Ephox Blogs , Personal Blog

Re: [whatwg] converting word (was attributes

[Charles McCathieNevile]

On Thu, 30 Apr 2009 13:25:17 +0200, Kristof Zelechovski  
 wrote:


Automatic conversion from Microsoft Word to HTML is doomed to fail  
because the document models and the requirements are different.

The best you can get is a tree of DIVs and SPANs with Word-
specific classes.  Anything better needs a serious and thoughtful
remake by the editor.


This is an oversimplification to the point of being misleading.

There are many ways to use Word, and many people and organisations with  
haf a clue use it in such a way that automatic conversion can be  
relatively easily used to generate highly semantically rich and valid  
markup - much better than the sort of tripe one typically finds on the Web  
today.


Word enabled the clear semantic markup of documents before HTML even  
existed, and people who use it like that are in a good position to produce  
HTML that is much better quality than most developers come up with. It  
also enables presentation-driven markup to be converted automatically to  
make the underlying semantics explicit (something that virtually no HTML  
tool outside those which convert from another input format manages to do).


This stuff is not rocket science, either. It is the sort of thing that was  
routine more than a decade ago when people started to use HTML as well as,  
or instead of, Word and similar formats.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: [whatwg] SVG extensions to

[Simon Pieters]

On Thu, 30 Apr 2009 21:15:04 +0200, Ian Hickson  wrote:


On Thu, 25 Oct 2007, Anne van Kesteren wrote:


For Opera 9.5 beta we implemented some experimental extensions to
 involving SVGSvgElement. SVGSvgElement is supported as "image"
argument to both drawImage and createPattern. (An HTMLImageElement
pointing to an SVG element is also supported, but that seems natural if
you support SVG from .)

For drawImage the pixel size of the SVG is determined as follows:

  1. The image size parameters passed to drawImage
  2. The intrinsic size of the SVG image
  3. 300 x 150

For createPattern it is as follows:

  1. The intrinsic size of the SVG image
  2. 300 x 150

(It would be nice if createPattern was extended to allow height/width
arguments as well.)

The intrinsic size of the SVG image is the specified size with
percentages resolved against 300 x 150, and sizes depending on the
font-size resolved against the computed font-size of the SVGSvgElement
(will be the browser default most of the time).

The SVG image is always rendered at time 0 for animated images.

Drawing an SVG image currently marks the canvas context as unsafe so
toDataURL() and getImageData() throw. We expect to make this story a bit
nicer at some point.


As far as I can tell this doesn't require any changes to HTML5, since the
same applies here as applies to a regular , right?


It would at least have to change to make it not throw...

"The image argument must be an instance of HTMLImageElement, HTMLCanvasElement, or 
HTMLVideoElement. If the image is of the wrong type or null, the implementation must 
raise a TYPE_MISMATCH_ERR exception."

--
Simon Pieters
Opera Software