404
results for "microformats hard"
-
one of the reasons for this was that a lot of the classic microformats parsers were necessarily based on hard-coded classnames, and they were a lot of work to maintain and went out of date quickly
barnaby
at
2021-06-12 21:04
-
if you’re using php-mf2, then you already have a DOMDocument available, which has done a lot of the hard work of resolving URLs, dealing with encodings, etc
barnabywalters
at
2021-05-25 19:32
-
I think part of that problem is that consuming HTML is hard. The mf2 parser makes it easier by narrowing down what HTML you have to deal with, but as soon as e-* properties are involved, consumers have to worry about potentially non-trivial transformations if they want to work with it
barnabywalters
at
2021-05-25 19:14
-
yeah this is hard to read :)
aaronpk
at
2021-04-23 23:39
-
Whether that's due to microformats h-card classed, or just Google using that text, is hard to say.
btrem
at
2021-04-08 02:19
-
I'm also hard pressed to think of a way to use MathML in microformats. Nothing comes to mind at the moment.
btrem
at
2021-04-08 01:28
-
But then, I'm hard-pressed to think of a reason for using anything other than the `<time>` element for a dt property.
btrem
at
2021-04-08 01:27
-
btrem: that could be done by doing a hard specification though
jacky
at
2021-02-20 03:28
-
There won't be any hard end to this catastrophe. It will sort of gradually get better. But it's hard for restaurants e.g. to determine "ok, now we should start rehiring." So things are very tenuous.
btrem
at
2021-02-20 03:10
-
agreed - a grid for an event is very useful -this isn't arbitrary nesting of events, it is the session grid that's needed, and it's been something we tried to come up with a way to add microformats to before and found it hard because of the implied time and venue from the grid. I think that is what drove the include pattern originally, though that probably is too complex.
[KevinMarks]
at
2021-01-16 06:23