I would go for the first one, since in this I think the br / is
given semantic value as a separator (even though, technically the
element has zero semantic value). The first set of markup would by
default display a nice, multi-line formatted address in all browsers
and could be formatted into a
Lea - I think the problematic part of the address / element as
described in Geoff's link is the part reading authorship for the
current document. Yes, wrapping a street address is correct. However,
it specifies that the address must be related directly to the document
(e.g. the author's or owner
Nothing 'wrong' with that I don't think. I think that the street
address should probably only be contained within a single dd, though
(since it is a single entity). Lines could be broken with br / as
appropraite.
I think it would then be appropraite to wrap the inner text of each
dd with an
graphic etc.
Ben
On 5/23/05, Ben Ward [EMAIL PROTECTED] wrote:
Nothing 'wrong' with that I don't think. I think that the street
address should probably only be contained within a single dd, though
(since it is a single entity). Lines could be broken with br / as
appropraite.
I think it would
Yes, it's an Internet Explorer wrapper. Another variation on the
Maxthon/Avant theme.
On 5/26/05, Thomas Livingston [EMAIL PROTECTED] wrote:
Curious about what The Pros ;-) thought of this.
Anyone got any insight/info/anecdotes/opinions? Is it a new wrapper
on IE? Is it compliant?
Ahh, but the problem with using blockquote there is that you're
trying to differentiate between content from the site owner and
content from contributors. However, both those people are 'authors' on
the blog, the blog article and blog comments are both first-hand
content.
blockquote marks up
I think the problem you have there is that you're breaking the
pictures down in too many different ways on a single page. You might
find it more managable if you allow users to choose the presentation:
For example, you can separate browsing by:
* Photographer
* Major catagory
* Country (maybe,
It is very much a legacy thing these days, since it is being solved
for XHTML 2.0, insofaras you can attach the href= attribute to
pretty much any element you like, regardless of block|inline
condition.
A navigation menu item could be 'li href=homepageHomepage/li'
without the extra a / tag.
What would be wrong with doing something like this?
h3Comment Title/h3
p
Posted by foobar on foobar
/p
div
p
Comment text
/p
/div
Nothing 'wrong', as such. The div surrounding the 'comment text'
paragraph is superfluous and could be dropped, but semantically it's
pretty sound.
The
Prabhath - code is an inline element, so while is should probably be
included somewhere in marking up code, you need something else on the
outside of it to create the block. pre is semantically pretty sound
for this, since code is pre-formatted and some languages are
white-space sensitive, for
The language in your html element should be the language of the page.
If you have a section of the page (be that a parapraph, form,
anything) which uses a different language then you can add a lang and
xml:lang attribute to that as well. HTML is generally rather good at
doing multi-lingual
If you're testing in Firefox 1.04 and Internet Explorer then there's
no need (unless you're doing ActiveX, in which case Netscape 8 has
some custom restrictions that you'd want to check against).
Just remember that it will take time for Netscape to stay up to date
with Firefox: When Fx1.1 arrives
Microformats.org have a nice little item in their FAQ about rel rev
and some very useful 'plain english' expansions of common rel and rev
relationships. It cetainly cleared a few things up for me!
Ben
On 7/13/05, Patrick H. Lauke [EMAIL PROTECTED] wrote:
Chris Kennon wrote:
After pouring
Use the object tag, just like we do with Flash. The SVG mimetype
(type atrribute) is image/svg+xml so you'd have something like:
object type=image/svg+xml data=image.svg
!-- fallback content --
/object
You can add width and heigh into that if you need to (though that
rather defeats the purpose
PROTECTED] wrote:
Ben Ward wrote:
Use the object tag, just like we do with Flash. The SVG mimetype
(type atrribute) is image/svg+xml so you'd have something like:
object type=image/svg+xml data=image.svg
!-- fallback content --
/object
would the fall back content maybe be a jpg, gif
Mac OSX has a system preference for 'Enable full keyboard access'
which in Safari at least is responsible for controlling whether you
can access form controls with the keyboard. Switching it on allows you
to do it.
I've left my Mac at home today, so haven't been able to check, but my
guess would
At the present time, Safari has minimal support for styled form
controls. Safari 2 on Tiger seems to support some colouring and
sizing, but little else. It was announced earlier in the week,
however, that the Safari team are working on a rewrite on their forms
code with a view to making them
Yes, it's already implemented in the development versions of Firefox.
If you download Deer Park Alpha 2 (for TESTING!), you should be able
to play with all the CSS improvements.
http://developer.mozilla.org/devnews/index.php/2005/07/12/deer-park-alpha-2-released/
Ben
http://ben-ward.co.uk
CSS 2 - W3C recommendation
CSS 2.1 - Working draft
Until CSS 2.1 becomes a recommendation, which shouldn't be too long
(deadline for comments was July), the W3C validator will use what ever
the current recommendation is.
Just to be a touch pedantic, CSS2.1 only needs to become a 'candidate
On the whole, I'm very much in the 'user decide' camp. However, there
is some argument for opening PDFs and other
'not-normally-browser-native' media types in new windows (citing the
confusing ways in which plug ins behave).
Personally, I like everything to download and be opened by a native
I'm not convinced that it can be done exactly as you describe.
Browsers - Mozilla for sure - have restrictions on what you can do
with external files - especially drag+drop. For example, the reason
you can't drag-and-drop a file onto a 'file' form control in Firefox
is because this would make it
I have generally tested in Opera 7+, but I do find that although its
standards support is generally outstanding, it pulls off some
genuinely odd quirks that can really mess you about.
One of the problems with targetting it came from the 'but people might
not pay to upgrade to version 7/8'
A few tips based on my experience of working with ASP.NET 1.1:
* First up, consider sticking to an HTML 4 DOCTYPE. It's really not as
big a deal as some advocates would have you think ;-) - Critically, if
you try and force it to use XHTML and someone accidentally clicks
'Design View' your code is
On 1/26/06, Miika Mäkinen [EMAIL PROTECTED] wrote:
Christian, that was my point... small atleast *sounds* presentational
(thought it could indicate text that is less important) and that was why I
wasn't happy to see it's included in HTML5...
On 3/14/06, James Ellis [EMAIL PROTECTED] wrote:
I've often wondered why these so-called tag clouds don't use big and
small tags (maybe they do ?)
they are inline tags. they convey meaning : 2 bigs is more important
than 1 big etc.
The problem there is that big and small tags _don't_ mean
25 matches
Mail list logo
