On 28 August 2013 14:32, Anne van Kesteren wrote:
> We have thought of three approaches for zip URL design thus far:
>
> * Using a sub-scheme (zip) with a zip-path (after !):
> zip:http://www.example.org/zip!image.gif
> * Introducing a zip-path (after %!): http://www.example.org/zip%!image.gif
>
Merci beaucoup Pierre. That was quite a detailed reply!
--
Nicholas.
On 1 October 2012 10:21, Michael[tm] Smith wrote:
> Don't look to that document for any information about default UA behavior,
> or anything at all about UA processing behavior. I tried to make that very
> clear in the abstract and intro for that document.
Sorry, I never saw that:
https://encryp
http://www.w3.org/TR/html-markup/th.html#th.attrs.scope Says nothing
about what a UA should do by default, nor when scope can be omitted
due to such defaults.
I suggest explicitly defining defaults for the benefit of both UAs and
HTML authors. I would expect the defaults to be defined something li
On 30 Jul 2008, at 4:49 am, Ian Hickson wrote:
On Tue, 20 Mar 2007, Nicholas Shanks wrote:
I asked for the resurrection of HTML+'s fallback
element
last month. The reasons I cited were exactly the same as the reasons
being given now in favour of the element, however I was
preference I can activate that
turns off all kinds of sniffing and hacks that the browser does to
support the ‘real internet’ (so, in this case, it would display text).
This would be incredibly useful as a debugging tool when working on
large web sites that I didn't author.
— Nicholas Sh
On 14 May 2008, at 12:11 AM, Ian Hickson wrote:
On Tue, 13 May 2008, Křištof Želechovski wrote:
Removing @rev is harmful for Lynx because that is how it decides
who the
author is.
Removing rev="" from the spec doesn't preclude Lynx still supporting
it
for legacy documents, and for new d
As
such, these kinds of abbreviations should not be marked up IMO, but
left to the synthesizer's lexicon.
> On Mon, 21 Apr 2008, Nicholas Shanks wrote:
> >
> > We need to go through this more methodically before making a decision. I
> > hope the following aids matters.
little blue underlined words and will and up far more
distracting than useful to users. Designers will also hate it, so it
will end up not being used at all.
Lastly, by disallowing the title attribute to be omitted you make
things unnecessarily difficult for currently valid HTML4 to migrate
resource
("file name"), the final part of the path.
I do not believe this is in scope for the specification. I don't see
an
interoperability issue here.
But it does sound like a potential security issue, re-titling external
documents.
— Nicholas Shanks.
smime.p7s
Desc
d decrease quality.
Re-encode it into ogg from the source material, and make sure your ogg
exporter settings are apropriate for the delivery medium you want.
— Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
hing pairs, and while still able to create those (e.g. two start
tags ending at the same ID; or pointing to non-extant IDs) the surface
area for error is greater if the end tag has to be the inverse of the
start tag too.
— Nicholas Shanks.
On 2 Apr 2008, at 4:05 pm, Daniel Glazman wrote:
addressed. Are
the elements necessary in HTML, should the information they convey be
specified in another manner completely?
[1] http://code.google.com/webstats/
— Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
On 1 Apr 2008, at 10:14 am, Benjamin Hawkes-Lewis wrote:
Nicholas Shanks wrote:
I know that everyone already knows this, but I think a reminder
might be timely:
Be careful not to confuse screen readers, who's job it is to read
what is displayed on the screen,
That's some
document into a DOM tree and apply media-less and aural
CSS (and potentially never display anything on screen).
visibility: hidden and display: none should both hide content from
screen readers.
— Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
investigating is if SSML could be embedded into HTML, using similar
principles as is being considered for SVG.
Lars Gunther
— Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
As not to render the content but to report it to screen
readers? Or maybe a element could be used to surround
content that shouldn't be displayed but should be accessible to
screen readers?
Any thoughts?
-Nicholas
Looking for last minute shopping deals? Find them fast with Yahoo!
Se
On 9 Jan 2008, at 16:54, Simon Pieters wrote:
Siemova wrote:
The easiest, most obvious solution would be to create an attribute
for Ordered Lists -- let's call it order="" -- which would have two
possible values: ftl (first to last) and ltf (last to first).
if we go this route, i'd prefer
On 27 Jun 2007, at 11:55, Robert O'Callahan wrote:
In my experience...
You do not know what you are talking about. Firefox does not use OS
image decoders.
And I don't use Firefox, so my point is still valid. Please don't
inform me of what you think I know or do not know, it is impolite.
On 27 Jun 2007, at 09:28, Maik Merten wrote:
Browsers don't rely on the OS to decode JPEG or PNG or GIF either
In my experience that seems to be exactly what they do do—rely on the
OS to provide image decoding (as with other AV media).
I say this because changes that had occurred in the OS (
I don't quite get some of the arguments in the thread.
Browsers don't (and shouldn't) include their own av decoders anyway.
Codec support is an operating system issue, and any browser installed
on my computer supports exactly the same set of codecs, which are the
ones made available via the OS
Various people have expressed opinions in favour of either one spec
to rule them all, or two specs for different audiences. Is not the
simplest solution to have two views upon the same spec?
HTML 5, Full Version (User Agent Edition)
" is deprecated and should not be used, but you have to supp
On 10 May 2007, at 08:45, Anne van Kesteren wrote:
On Thu, 10 May 2007 09:02:52 +0200, Nicholas Shanks
<[EMAIL PROTECTED]> wrote:
Would it not make more sense to fix the UAs.
lower-case hex is horrible to read.
Feel free to convince the Microsoft Internet Explorer team. Then
again
On 10 May 2007, at 07:31, Ian Hickson wrote:
On Tue, 29 Aug 2006, Anne van Kesteren wrote:
Instead of returning an uppercase six digit hex value I suggest
returning a lowercase value for compatibility with what UAs
(including
IE) currently do for CSS already and what Mozilla already does fo
May I suggest that you also allow the DOM "referrer" attribute to
match a HTTP "Referrer" header if one is present, and fall back to
the "Referer" header otherwise. This provides for HTML 5 compliant
UAs to be forwards compatible with a potential future HTTP spec that
fixes the typo.
Also
I have a website which discusses typography, web design, and computer
fonts. It recently occurred to me that my use of spans with style
elements was not really the most semantic method of getting across my
meaning, and I would be better using the font element.
My content goes something like
On 12 Apr 2007, at 18:11, Charles Iliya Krempeaux wrote:
Hello,
Do any of the existing web archive formats out there store the
"ETag" or "Last-Modified" of the resources it is archiving?
I think all the headers should be saved, especially Location, Content-
Type, Content-Language, Last-Mod
On 7 Apr 2007, at 23:48, David Håsäther wrote:
Markup starting with "
Yeah, sorry. I added the doctype bit after and forgot to go
back and amend the introductory statement. Consider the question to
be "tags and declarations that don't start with
On 7 Apr 2007, at 15:47, Anne van Kesteren wrote:
On Sat, 07 Apr 2007 14:27:14 +0200, Nicholas Shanks
<[EMAIL PROTECTED]> wrote:
AFAIK browsers and other HTML clients don't currently treat these as
comments, [...]
Well, sorry to say, you got your facts wrong.
*sigh*
I guess
On 7 Apr 2007, at 02:56, Anne van Kesteren wrote:
The tokenization section should also handle:
as "correct" comments for compat with the web. This means that
shows "-->" and that
shows "-->".
Why on earth is this a good idea?
AFAIK browsers and other HTML clients don't currently
On 4 Apr 2007, at 08:03, Vladimir Vukicevic wrote:
I do agree that the codec discussion should be tabled
I think you mean shelved. Or did you mean we have hit a wall here, so
shelve it and get the chair to table it on the W3C floor? :-)
- Nicholas.
smime.p7s
Description: S/MIME crypto
On 2 Apr 2007, at 11:35, Asbjørn Ulsberg wrote:
With CSS2.1, how would you style the button you get from an type="file"> for instance?
I don't know about other UAs, but in Safari one would use the selector:
input[type="file"]::-webkit-file-upload-button
- Nicholas.
smime.p7s
Description:
On 25 Mar 2007, at 23:13, Simon Pieters wrote:
The current draft of HTML5 has an automatic cross-reference feature
with the span, abbr, code, var, samp, and i elements, which would
point to a matching element.
I don't see tens of thousands of web developers crying out for this
kind of fe
On 24 Mar 2007, at 16:57, Anne van Kesteren wrote:
The dateTime DOM attribute is spelled with an uppercase T:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-79359609
I just encountered that while implementing longdesc support. The IMG
attribute is lower-case, the DOM attribute is longDes
On 23 Mar 2007, at 18:26, Robert Brodrecht wrote:
I welcome to mark up blocks of code, but I don't think HTML
should go further than that, if you want to mark up computer
code that badly, use XHTML + some CodeML equivalent to MathML.
I'd love to, but one of the major browsers doesn't supp
On 23 Mar 2007, at 20:47, Maciej Stachowiak wrote:
I agree the repetition of source/src is a little weird.
and name the new element something like
I don't like abbreviations such as alt and src.
The use case is uncommon enough that wouldn't be too much
of a burden to type and ought to prov
On 23 Mar 2007, at 17:59, Henri Sivonen wrote:
pretending that doesn't exist won't make applets
disappear. :-(
Perhaps not, but this will:
applet { display: none !important; }
:o)
- Nicholas.
smime.p7s
Description: S/MIME cryptographic signature
On 23 Mar 2007, at 13:17, Anne van Kesteren wrote:
On Fri, 23 Mar 2007 13:40:47 +0100, Nicholas Shanks
<[EMAIL PROTECTED]> wrote:
Mostly unused, not even deprecated, these elements bloat the spec,
confuse lay authors (i.e. those not of a computer science background)
and I feel would be
On 23 Mar 2007, at 02:27, Robert Brodrecht wrote:
Just because "most ... doesn't bother" doesn't mean it ought to be
removed.
So let's not ignore elements because "no one uses them."
Ignore them because they are useless.
I was thinking more along the lines of:
1) We start with a set contain
On 23 Mar 2007, at 01:30, Sander Tekelenburg wrote:
(Note that a mechanism to allow authors to define anchors in videos
is not a
solution, because it's then still the author who is in control.
What I'm
suggesting is about giving the user control.)
Can't we have all of:
1) A way for authors
Continuing today's flood of emails from me to this list, here's another.
Note: I never bothered to read this thread the first time, but since
Henri has brought to the top of my email client again, I started from
the beginning.
I want to comment on the eight bullets given at:
http://www.alleg
On 22 Mar 2007, at 20:53, Silvia Pfeiffer wrote:
Sorry to jump into this conversation at such a late point, but I only
just joined the mailing list.
About 8 years ago, we had the idea of using fragment offsets to start
playing from offsets of media files. However, in discussions with the
URI st
On 22 Mar 2007, at 19:23, Sander Tekelenburg wrote:
At 18:31 + UTC, on 2007-03-21, Nicholas Shanks wrote:
On 21 Mar 2007, at 12:43, Sander Tekelenburg wrote:
I'd like to see the spec to
require UAs support implicit anchors, so that one can link to a
specific startpoint:
On 22 Mar 2007, at 16:11, Robert Sayre wrote:
On 3/22/07, Gervase Markham <[EMAIL PROTECTED]> wrote:
Would it not have made more sense to at least have asked the WHAT-WG
No.
I think you're wrong and clearly I'm not alone. In fact I think legal
matters *should* be discussed here and advoc
On 22 Mar 2007, at 16:02, Gervase Markham wrote:
i.e. removing all chrome...
What is "chrome" ?
I mean, I know what it really is, but that seems to have nothing to
do with computers or web browsers (except for the chromium-coloured
iPod phone).
- Nicholas.
smime.p7s
Description: S/MI
On 22 Mar 2007, at 14:16, Gervase Markham wrote:
Martin Atkins wrote:
Perhaps you and I have different ideas about what is meant by
"full screen", but why would a page need to hide anything when the
video is full screen? The page itself won't be visible, because
the video will be taking up
On 22 Mar 2007, at 00:08, Maciej Stachowiak proposed:
CSS Timed Media Module
HTML Timed Media Elements
• On volume:
The volume property is currently inconsistent in the string names
defined:
http://webkit.org/specs/Timed_Media_CSS.html#propdef-volume
Value: reads "silent | soft | medium |
On 21 Mar 2007, at 12:43, Sander Tekelenburg wrote:
Something else concerning first-class Netizenry: I'd like to see
the spec to
require UAs support implicit anchors, so that one can link to a
specific
startpoint: http://domain.example/movie.ogg#21:08>, to mean
"fetch the
movie and start pl
On 21 Mar 2007, at 09:37, Henri Sivonen wrote:
OTOH, the left/right alignment of table cells *is* often tightly
coupled with the cell data, which suggests that the cell alignment
attributes should not be dropped.
Alternatively it could just be allowed on the and ,
where it would affect
On 21 Mar 2007, at 00:27, Simon Pieters wrote:
I asked for the resurrection of HTML+'s fallback
element last month. I was told that would break existing
implementations
Existing implementations include at least:
* Internet Explorer
* Firefox
* Opera
* Safari
The start tag is parsed as
On 17 Mar 2007, at 23:28, Andrew Fedoniouk wrote:
I think that in most cases will be better if we could package
complex pages into zip envelopes and deliver them in the whole.
That would be real solution of "jumps". And height=...>
is a palliative.
I have an open bug with Safari requesting s
On 20 Mar 2007, at 21:50, Benjamin Hawkes-Lewis wrote:
Ian Hickson wrote:
However, I think if is so widely derided by everyone,
than I
think it needs to be depreciated sooner rather than later.
I have seriously considered doing this. Unfortunately I don't
think we can
actually do it gi
Given XHTML 2.0's idea of an element for navigation list (using
as the tag [1]), it occurred to me that , deprecated in HTML 4
but resurrected in HTML 5, would be entirely suitable for this
purpose and fully backwards compatible. From what I can gather, this
was the intended purpose of the
On 16 Mar 2007, at 15:32, Shadow2531 wrote:
.loop, .startpos
loop = false | true
autostart = true | false
startpos = 0 | specified pos
Could you elaborate on the use cases for these?
The downside of that is sites have to implement a cookie system. I
don't want to do that on my own
On 16 Mar 2007, at 11:03, Magnus Kristiansen wrote:
When I think of playlists, the first thing that comes to mind are
commercials. Some video sites show ad or promotion clips before and/
or after the main video. I imagine they'd see that as a use case.
It could also be used to create medleys
Discussion on aspect ratio:
You may want to consider aspect ratio too: ratio="preserve" being
default, ratio="1.333" could indicate 4:3 or get tricky and accept
"16:9" for precision reasons.
Wouldn't we simply always want to use the authored size?
Do videos encode what size they are best dis
On 28 Feb 2007, at 05:38, Ian Hickson wrote:
For example, your page-wide header might need shortening on
handheld media. I don't have a good proposal for this. Maybe we
need the opposite of ?
We already have the opposite of the abbr element. It's called… the
abbr attribute (for th element
On 12 Mar 2007, at 20:19, Andrew Fedoniouk wrote:
Case:
xyz
xyz-xyz-xyz
is perfectly valid from some abstract semantic machine
point of view but for human these two cells are not
equal. At least hit area is different. And visual perception too.
All you need to do is add this to your CSS:
td >
On 2 Mar 2007, at 17:00, Alexey Feldgendler wrote:
Likewise, HTML has to explicitly express the semantics of a
hyperlink. I don't see how the language would benefit from the
ability of turning any element into a link.
The main use I would put it to is on elements, especially tables
of c
On 2 Mar 2007, at 10:01, Gervase Markham wrote:
I think a base format is vital. With we had de-facto standard
formats because of what the first browsers supported. It took ages
to get another one added (PNG) and it wasn't widely used until
browser support firmed up.
If a base format can'
On 1 Mar 2007, at 11:56, Anne van Kesteren wrote:
That's one of the reasons a dedicated element is better than
reusing the element. All the new video specific APIs would
otherwise have to be defined for all possible things the
element can represent (images, nested browser context, video,
On 12 Feb 2007, at 16:40, David Latapie wrote:
The rationale was that the difference between and
is
presentational.
CERN
FBI
NASA
Leut.
Why do you use both and ?
The way I see it
Abbreviation
Hyperonym (superset) for initialisms and acronyms
Acronym
Abbreviation that yo
On 9 Feb 2007, at 17:19, David Latapie wrote:
- small: It does not cope well inline. I (almost) never use small in a
paragraph; I use it for one-liners, e.g. source: or
No this is a long post, right?
Agreed, when I use small, which these days is just for things like
post author and date on m
On 9 Feb 2007, at 15:51, Benjamin Hawkes-Lewis wrote:
Nicholas Shanks wrote:
Yes, like OBJECT, but with a different name. A nicer name than
IMG. One
with three vowels. One that only accepts image/* content types. One
with a more specific usage that can be controlled independently of
OBJECT
On 9 Feb 2007, at 07:47, Karl Dubost wrote:
Le 8 févr. 2007 à 20:17, Nicholas Shanks a écrit :
On 6 Feb 2007, at 07:57, Karl Dubost wrote:
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
I wish the fallback tags had made it through the
years. It's so much better than and doesn'
On 8 Feb 2007, at 22:31, Henri Sivonen wrote:
On Feb 8, 2007, at 21:09, Nicholas Shanks wrote:
, , or other new element
What would the default visual presentation be?
One or more of:
none (i.e. same as span: 'inherit everything')
opacity: 0.8
font-size: smaller
parentheses ::
On 6 Feb 2007, at 07:57, Karl Dubost wrote:
unlikely. "div" and "span" elements didn't exist in HTML+.
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
Ironically I was just reading that earlier today, then saw your post!
(I hadn't been reading this thread.)
I wish the fallback tags had
So there have been a number of complaints that the only way to de-
emphasize something is via . I am one such complaining voice.
There have been several suggested solutions proposed too. I would
like to give my opinions on a few of those:
or similar attribute
My concern here is whether th
On 8 Feb 2007, at 18:00, David Latapie wrote:
Problem with / is that its meaning is confusing.
I don't think it's any more confusing than would be. See below...
And still don't see any difference with or . How would
you
pronounce an important word? How would you pronounce a highlighted
w
On 8 Feb 2007, at 15:23, Leons Petrazickis wrote:
In the Western world, the standard for highlighting is a neon yellow
background. I submit that a much better name for is
(, , ).
I don't like the look of "" — it doesn't tell me what it does
very well. Maybe it stands for Horizontal Italic,
On concern that we would be 'wasting' such a short element name for
such an esoteric usage, why not call it instead?
- Nicholas.
smime.p7s
Description: S/MIME cryptographic signature
Having come in to this conversation half way, I'd like to give my
opinions. In the following 'default style' means in the UAs style
declarations for all documents of the language.
There should be three emphasis elements:
Increases emphatic semantics by one level. *No* default
rendering s
On 5 Sep 2006, at 12:54, Charles McCathieNevile wrote:
Instead of returning an uppercase six digit hex value I suggest
returning a lowercase value for compatibility with what UAs
(including IE) currently do
It may be the right decision on compatibility grounds, but other
than that lowerca
Hi Håkon, thanks for replying.
Why not just follow the guidelines in the CSS3 font module?:
Ahh, I didn't see there were instructions on the module itself on
where to send suggestions, and it doesn't give the main author's name
(just "the CSS2 authors and Tantek…" et al).
I was on that css
t a web
designer will append "Arial" before the generic family—making the
generics almost useless in that regard—due to the lack of universal
fonts for either of these generics a user agent would likely find it
falls back to them much more often than for 'serif' and 'sans-serif'.
- Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
75 matches
Mail list logo
